From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Fehlig <jfehlig@suse.com>
Subject: Re: [RFC] support more qdisk types
Date: Wed, 27 Jan 2016 19:27:04 -0700
Message-ID: <56A97C78.2020704@suse.com>
References: <56A6BCDE.6040900@suse.com>
	<20160127183220.GC3134@char.us.oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20160127183220.GC3134@char.us.oracle.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ken Johnson <ken@suse.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 01/27/2016 11:32 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 25, 2016 at 05:25:02PM -0700, Jim Fehlig wrote:
>> 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.
> ssh?

http://qemu.weilnetz.de/qemu-doc.html#disk_005fimages_005fssh

>> 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
> Either way - new backends would require changes in both libxl and libvirt right?

The backend is not new, it's qdisk. I'm suggesting to support more qdisk types.
But yes, it requires changes to libxl, xl, and libvirt.

> The libxl would need to understand the new 'target=' blob to parse it out?

Right, that's one approach. The config info is encoded in 'target=' in a
specified format, and libxl parses it out. Another approach is libxl provides
more settings for specifying these qdisk types.

Regards,
Jim