[libvirt] [PATCH 3/6] Introduce new XMLs to specify disk source using storage pool/vol

[Osier Yang]

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

Osier