On 02/24/2014 09:53 AM, Eric Blake wrote:
On 02/24/2014 08:48 AM, Peter Krempa wrote:
> One further thing we should discuss is the block copy job, where we need
> to specify a new path that is not part of the backing chain of the disk
> where the disk gets copied (and efectively becomes the new single
> element of the backing chain). The for this operation has a very similar
> interface which we need to figure out too sooner or later.
For that interface, I wonder if the best approach is to add a new flag.
By default, when the flag is 0, the new disk string is treated as a
path name in the local file system. But when the flag is set, the new
disk string is treated as an XML document describing the full <disk>
details, which gives us the full flexibility for a volume within a
storage pool or the full details of a network device such as gluster, or
even a network device that has multiple <host> subelements.
[I hit send too soon]
That is, the shorthand of "vda[1]" or "vda[2]" for referring to
elements
already in the existing block chain works nicely for blockpull and
blockcommit; and for blockcopy, reusing existing XML notations for
specifying a network destination, the same way we just recently taught
snapshots to reuse XML notations, seems like the best way for
designating the new location. And since we were smart enough to have a
flag argument, I'm fine with using the flag argument for the
determination of whether a file string is a local filename vs. an XML
<disk> designation.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org