On 06/25/2014 12:13 PM, Adam Litke wrote: > On 25/06/14 10:27 -0600, Eric Blake wrote: >> On 06/19/2014 07:59 AM, Peter Krempa wrote: >>> Now that we are able to select images from the backing chain via indexed >>> access we should also convert possible network sources to >>> qemu-compatible strings before passing them to qemu. >> >> Eventually, we'll want to use qemu's node-name functionality, also being >> added (but possibly in qemu 2.2 instead of 2.1, depends on how Jeff's >> series goes). But for the simpler case of all files being local or all >> files being network from the same pool (that is, no mixed-mode chains), >> then this does appear to work at getting a decent name into qemu, at >> which point qemu can indeed commit to the right target. >> >> Wait - the earlier patches said that relative names would be preserved >> if possible, implying that an absolute name would still be used if a >> relative name was not possible. But this errors out if a relative name >> was not possible. Which is nicer to the end user, treating the flag as >> advisory or mandatory? I'm hoping Adam can answer which he'd prefer, as >> one of the first clients of this new feature. > > Thanks Eric. If the flag was specified we need it to fail if a > relative backing path is not possible. Otherwise the backing chain > could be rewritten such that the VM can not be started on a different > host in the future. For us, not honoring the flag is a corruption. > Okay, let's go with mandatory semantics on the respin of this series. If the flag is present, we fail unless we were able to write a relative name into the affected file (which implies that using the flag while the chain already had absolute names is a guaranteed failure). > For those applications that don't mind (or might handle abs paths > differently than relative ones, they could retry the operation without > the flag. Perhaps we'll want a specific error code for this scenario > to make it easy to handle? I wouldn't bother with a special error code unless someone specifically asks for it in their use case. We can always add it later, if needed. -- 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