From patchwork Tue Jan 26 00:25:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jim Fehlig X-Patchwork-Id: 8117031 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id DAB989F38B for ; Tue, 26 Jan 2016 00:28:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D6DA02034F for ; Tue, 26 Jan 2016 00:28:24 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9EC52034C for ; Tue, 26 Jan 2016 00:28:23 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aNrRf-00067V-Sm; Tue, 26 Jan 2016 00:25:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aNrRe-00067Q-BD for xen-devel@lists.xen.org; Tue, 26 Jan 2016 00:25:18 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 59/F7-23366-DECB6A65; Tue, 26 Jan 2016 00:25:17 +0000 X-Env-Sender: jfehlig@suse.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1453767914!19345223!1 X-Originating-IP: [137.65.250.81] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11152 invoked from network); 26 Jan 2016 00:25:15 -0000 Received: from smtp2.provo.novell.com (HELO smtp2.provo.novell.com) (137.65.250.81) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 26 Jan 2016 00:25:15 -0000 Received: from [192.168.0.28] (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by smtp2.provo.novell.com with ESMTP (TLS encrypted); Mon, 25 Jan 2016 17:25:03 -0700 Message-ID: <56A6BCDE.6040900@suse.com> Date: Mon, 25 Jan 2016 17:25:02 -0700 From: Jim Fehlig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-devel Cc: Ian Jackson , Wei Liu , Ian Campbell , Ken Johnson Subject: [Xen-devel] [RFC] support more qdisk types X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I would like to hear the community's opinion on supporting more qdisk types in xl/libxl, e.g. nbd, rbd, iSCSI, etc. I prefer supporting additional qdisk types in libxl over apps like xl or libvirt doing all the setup, producing a block device, and then passing that to libxl. Each libxl app would have to re-implement functionality already provided by qdisk. libxl already supports IDE, AHCI, SCSI, and Xen PV qdisks. My suggestion is to extend that to initially include nbd, rbd, and iSCSI. Sheepdog, ssh, etc. could be added in the future. I considered several approaches to supporting additional qdisk types, based primarily on changes to the disk cfg and interface. At one extreme is to change nothing and use the existing 'target=' to encode all required config for the additional qdisk types. libxl would need to be taught how to turn the blob into an appropriate qdisk. At the other extreme is extending xl-disk-configuration with discrete knobs for each possible config item and making the libxl_device_disk structure more hierarchical. E.g. libxl_device_disk { ... existing libxl_device_disk_source src; } libxl_device_disk_source { libxl_disk_source_protocol protocol; int num_hosts; libxl_disk_source_host hosts; libxl_disk_source_auth auth; } enum libxl_disk_source_protocol { LIBXL_DISK_SOURCE_PROTOCOL_UNKNOWN = 0, LIBXL_DISK_SOURCE_PROTOCOL_NBD = 1, LIBXL_DISK_SOURCE_PROTOCOL_RBD = 2, LIBXL_DISK_SOURCE_PROTOCOL_ISCSI = 3, } libxl_disk_source_host { char *name; int port; } libxl_disk_source_auth { char *user; char *data; } As an initial RFC, I took a stab at something in the middle, adding a few items to the xl-disk-configuration and libxl_device_disk. Attached is a patch to the doc and IDL illustrating the proposal. Suggests, comments, and feedback warmly welcomed. Regards, Jim From 3a6aeb434506c620dd122b9ff19656bcdd35f081 Mon Sep 17 00:00:00 2001 From: Jim Fehlig Date: Mon, 25 Jan 2016 16:57:42 -0700 Subject: [PATCH] [RFC] support more qdisk types Extend xl-disk-configuration to include settings needed to support nbd, rbd, and iSCSI qdisks. Add corresponding fields to the libxl_device_disk structure. Signed-off-by: Jim Fehlig --- docs/misc/xl-disk-configuration.txt | 43 +++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_types.idl | 12 +++++++++++ 2 files changed, 55 insertions(+) diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-configuration.txt index 6a2118d..87a6560 100644 --- a/docs/misc/xl-disk-configuration.txt +++ b/docs/misc/xl-disk-configuration.txt @@ -168,6 +168,49 @@ Normally this option should not be specified, in which case libxl will automatically determine the most suitable backend. +backendprotocol= +---------------------------------- + +Description: Specifies the protocol used by the qdisk backend + when accessing a network-based disk +Supported values: nbd, rbd, iscsi +Mandatory: No + +backendprotocol is only supported by the qdisk backendtype. nbd uses +QEMU's internal network block device implementation. rbd uses QEMU's +integration with librados to natively access block devices on Ceph +clusters. iscsi uses QEMU's integration with libisci to access iSCSI +resources. + + +server= +------------------ + +Description: Specifies a host and port providing access to a + network-based disk +Supported values: Valid host:port pairs +Mandatory: No + +server is only supported by the qdisk backendtype. host can be a valid +hostname or host IP address. Some backendprotocol's such as rbd allow +specifying multiple servers for accessing a network-based disk. + + +auth= +---------------- + +Description: Specifies authentication information for a + network-based disk +Supported values: backendprotocol dependent +Mandatory: No + +auth is only supported by the qdisk backendtype. rbd supports cephx +authentication, where 'user' would be the Ceph user and 'data' the +user's base64-encoded cephx key obtained with 'ceph auth get-key '. +iscsi supports CHAP username/password, in which case 'data' contains the +user's password. + + script=