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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list