[libvirt] [PATCHv5 18/19] qemu: Add support for networked disks for block commit

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140625/41c7f3bd/attachment-0001.sig>