From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <ian.campbell@citrix.com>, Wei Liu <wei.liu2@citrix.com>
Cc: Ken Johnson <ken@suse.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC] support more qdisk types
Date: Mon, 08 Feb 2016 17:54:45 -0700 [thread overview]
Message-ID: <56B938D5.6070409@suse.com> (raw)
In-Reply-To: <56B2BD31.3030909@suse.com>
On 02/03/2016 07:53 PM, Jim Fehlig wrote:
> On 02/03/2016 02:56 AM, Ian Campbell wrote:
>> On Tue, 2016-02-02 at 15:06 -0700, Jim Fehlig wrote:
>>>> And extending
>>>> the structure seems to be the right thing to do.
>>> So what do you think of the approach in the RFC patch? It adds discrete knobs in
>>> the disk config and extends the disk structure similarly. Before I can make
>>> progress on this we need to agree on extending the config and libxl_device_disk
>>> structure.
>> My main concern is that this approach requires us to update libxl for each
>> new possible backend type.
> Yes, understood.
>
>> The intention of the target= in the disk spec is that it consumes the rest
>> of the line so it can be used to encode pretty much anything. Is it not
>> possible (modulo bugs) to pass all the necessary information to qdisk in
>> this form? I thought Dave S had made it possible to use qdisk in this way
>> back in:
>>
>> commit a8a1f236a2964506a22d1779648d8e1c8668cb1a
>> Author: David Scott < dave.scott@eu.citrix.com >
>> Date: Tue Apr 23 10:59:26 2013 +0100
>>
>> libxl: Only call stat() when adding a disk if we expect a device to exist.
>>
>> We consider calling stat() a helpful error check in the following
>> circumstances only:
>> 1. the disk backend type must be PHYsical
>> 2. the disk backend domain must be the same as the running libxl
>> code (ie LIBXL_TOOLSTACK_DOMID)
>> 3. there must not be a hotplug script because this would imply that
>> the device won't be created until after the hotplug script has
>> run.
>>
>> With this fix, it is possible to use qemu's built-in block drivers
>> such as ceph/rbd, with a xl config disk spec like this:
>>
>> disk=[ 'backendtype=qdisk,format=raw,vdev=hda,access=rw,target=rbd:rbd/ubuntu1204.img' ]
> I thought I tried disk config along those lines with no success. But I'll
> certainly take a closer look at using target= to encode the config needed by
> these qdisk block drivers. Thanks for the pointer.
I think my previous problem was related to quoting in a disk spec containing
several ceph monitors. According to $qemu-src/hw/block/rbd.c, ':' is used to
delimit option=value tuples. I was escaping the colon between a ceph monitor
server and port with a single '\'. E.g.
disk = [ "vdev=xvdb, backendtype=qdisk,
target=rbd:libvirt-pool/new-libvirt-image:auth_supported=none:mon_host=192.168.0.100\:6789;192.168.0.101\:6789;192.168.0.102\:6789"
]
What I didn't realize was that libxl omitted the entire colon when writing the
string to xenstore
xenstore-read /local/domain/0/backend/qdisk/55/51728/params
aio:rbd:libvirt-pool/new-libvirt-image:auth_supported=none:mon_host=192.168.0.1006789;192.168.0.1016789;192.168.0.1026789
which caused the rbd block driver to barf. Using double backslash worked. E.g.
disk = [ "vdev=xvdb, backendtype=qdisk,
target=rbd:libvirt-pool/new-libvirt-image:auth_supported=none:mon_host=192.168.0.100\\:6789;192.168.0.101\\:6789;192.168.0.102\\:6789"
]
with corresponding xenstore entry
aio:rbd:libvirt-pool/new-libvirt-image:auth_supported=none:mon_host=192.168.0.100\:6789;192.168.0.101\:6789;192.168.0.102\:6789
Note that specifying server:port in nbd doesn't require quoting the colon. The
following config works just fine
disk = [ "vdev=xvdb, backendtype=qdisk, target=nbd:192.168.0.150:5555"
In the end, maybe all that's needed is a few more examples in
xl-disk-configuration. Perhaps a paragraph under "Special Syntax" of 'target'
doc, along with example config like the above?
Regards,
Jim
next prev parent reply other threads:[~2016-02-09 0:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 0:25 [RFC] support more qdisk types Jim Fehlig
2016-01-27 18:32 ` Konrad Rzeszutek Wilk
2016-01-27 20:25 ` Doug Goldstein
2016-01-27 21:09 ` Konrad Rzeszutek Wilk
2016-01-28 2:42 ` Jim Fehlig
2016-01-29 14:07 ` Konrad Rzeszutek Wilk
2016-01-29 17:18 ` Jim Fehlig
2016-01-29 17:59 ` Konrad Rzeszutek Wilk
2016-01-28 2:37 ` Jim Fehlig
2016-01-29 14:21 ` Doug Goldstein
2016-01-28 2:27 ` Jim Fehlig
2016-02-02 14:59 ` Wei Liu
2016-02-02 22:06 ` Jim Fehlig
2016-02-03 9:56 ` Ian Campbell
2016-02-04 2:53 ` Jim Fehlig
2016-02-04 10:16 ` Ian Campbell
2016-02-09 0:54 ` Jim Fehlig [this message]
2016-02-09 9:35 ` Ian Campbell
2016-02-09 10:58 ` Ian Jackson
2016-02-03 10:35 ` Wei Liu
2016-02-03 10:51 ` Ian Campbell
2016-02-03 10:55 ` Wei Liu
2016-02-03 11:05 ` Ian Campbell
2016-02-03 11:08 ` Wei Liu
2016-02-03 11:15 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B938D5.6070409@suse.com \
--to=jfehlig@suse.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ken@suse.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).