Re: [libvirt] [PATCH 3/6] Introduce new XMLs to specify disk source using storage pool/vol
On 01/23/2013 10:24 AM, Osier Yang wrote:
On 2013年01月23日 22:58, Daniel P. Berrange wrote:
> On Wed, Jan 23, 2013 at 10:55:25PM +0800, Osier Yang wrote:
>> On 2013年01月23日 22:18, Daniel P. Berrange wrote:
>>> On Wed, Jan 23, 2013 at 07:04:35PM +0800, Osier Yang wrote:
>>>> With this patch, one can specify the disk source using storage
>>>> pool/volume like:
>>>>
>>>> <disk type='file' device='disk'>
>>>> <driver name='qemu' type='raw'
cache='none'/>
>>>> <source type='pool'>
>>>> <volume key='/var/lib/libvirt/images/foo.img'/>
>>>> <seclabel relabel='no'/>
>>>> </source>
>>>> <target dev='vdb' bus='virtio'/>
>>>> </disk>
>>>>
>>>> <disk type='file' device='disk'>
>>>> <driver name='qemu' type='raw'
cache='none'/>
>>>> <source type='pool'>
>>>> <volume path='/var/lib/libvirt/images/foo.img'/>
>>>> <seclabel relabel='no'/>
>>>> </source>
>>>> <target dev='vdb' bus='virtio'/>
>>>> </disk>
>>>>
>>>> <disk type='file' device='disk'>
>>>> <driver name='qemu' type='raw'
cache='none'/>
>>>> <source type='pool'>
>>>> <pool uuid|name="$var"/>
>>>> <volume name='foo.img'/>
>>>> <seclabel relabel='no'/>
>>>> </source>
>>>> <target dev='vdb' bus='virtio'/>
>>>> </disk>
>>>
>>>
>>> If you're going to introduce new schema for<source>,
>>> then you must introduce a new disk type value.ie a
>>> <disk type='file'> must always use the<source
file='...'/>
>>> XML syntax, otherwise you cause backwards compatibility
>>> problems for applications
>>
>> Oh, yes. I need a v2.
>>
>>>
>>> What you need here is a<disk type='volume'/> for your
>>> new schema.
>>>
>>
>> But before I make up the v2, do you see other design problem
>> on the set? Thanks.
>
> I'm wondering if it is really requires to allow so many different
> options for specifyin the pool& volume. For<interface
type='network'>
> we were fine simply using the 'name' and ignoring UUID. I cna't help
> thinking that for storage we can similarly just use the pool name and
> volume name
>
This was my hesitating too when on the half road. But to post the RFC
earlier, and considering it's at least not a bad thing, as we provide
all the interfaces, so I went on with it.
I think it makes no big difference if we simply use pool name and
volume name, but what I'm not sure is if the users will want the uuid
for pool, and path/key for volume (using path/key is convenient
as the pool is not even neccessary).
(Keep in mind this is coming from a non-storage guy, so there may be
some flaws in my logic :-)
Too many ways of describing the same thing is bad, as it leads to confusion.
Also, since the point of making this abstraction is to isolate the
host-specific details of the device from the domain's configuration, I
think allowing the file path to be specified is counter-productive
(since it could be different from host to host, depending on where an
NFS share is mounted, for example).
Of course this is a bit of a different situation than network devices,
since the pool/volume must end up pointing to the same bits from all
hosts (either the exact same bits via a different access path, or a new
copy of the bits migrated over to a different type of storage), but in
the end it should be possible for the disk image to be in a local
directory on one host, accessed by NFS on another, and maybe even via
iscsi or lvm on another - those details should all be in the pool/volume
definitions on each host, and the guest config should just say "this
disk's image is in pool x, volume y".