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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list