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

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

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list