[libvirt] [PATCHv5 19/19] qemu: Add support for networked disks for block pull/block rebase
Adam Litke
alitke at redhat.com
Wed Jun 25 18:15:28 UTC 2014
On 25/06/14 10:34 -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.
>> ---
>> src/qemu/qemu_driver.c | 45 +++++++++++++++++++++++++++++++++++++++++----
>> 1 file changed, 41 insertions(+), 4 deletions(-)
>
>Same caveats as in 18/19 about not necessarily working in mixed-source
>chains (for that, we'd need to use node-names); but as it is definitely
>more powerful than what libvirt previously supported, it's still worth
>including under the incremental improvement umbrella.
>
>
>> @@ -15040,6 +15042,13 @@ qemuDomainBlockJobImpl(virDomainObjPtr vm,
>> goto cleanup;
>> }
>>
>> + if (flags & VIR_DOMAIN_BLOCK_REBASE_RELATIVE && !base) {
>> + virReportError(VIR_ERR_INVALID_ARG, "%s",
>> + _("flag VIR_DOMAIN_BLOCK_REBASE_RELATIVE is valid only "
>> + " with non-null base "));
>
>Trailing space in the error message. This treats relative name with no
>base as a hard error, which is okay but should be documented.
>
>> +
>> + if (!backingPath) {
>> + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
>> + _("Can't keep relative backing relationship."));
>
>No trailing '.'. Once again, back to the question of whether it is
>nicer for the flag to be advisory (best effort to use relative, but
>absolute fallback is okay) or mandatory (fail if the request cannot be
>honored).
>
>At this point, I'm leaning towards mandatory (it's easier to relax
>mandatory to advisory later than it is to give advisory now and tighten
>it up later; and I like to know if my explicit request cannot be
>honored). But the documentation needs to match what we choose, and it
>would help to have Adam's insight as a client of this flag.
See response to 18... Mandatory is our strict requirement.
--
Adam Litke
More information about the libvir-list
mailing list