On Mon, Feb 24, 2014 at 09:53:59AM -0700, 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. If we want to allow XML instead of a path, then I'd suggest we really should create a new API instead of overloading the semantics of 'path'. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list