xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).