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

[Laine Stump]

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