On 11/05/2015 10:40 AM, Paolo Bonzini wrote:
>
>
> On 05/11/2015 18:37, Max Reitz wrote:
>> $ x86_64-softmmu/qemu-system-x86_64 -qmp stdio \ -drive
>> if=none,file=test.qcow2,id=drive0,node-name=node0 {"QMP":
>> {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
>> "package": ""}, "capabilities": []}}
>> {'execute':'qmp_capabilities'} {"return": {}}
>> {'execute':'drive-backup','arguments':{'device':'drive0','target':'out.qcow2','format':'qcow2','sync':'none'}}
>>
>>
> Formatting 'out.qcow2', fmt=qcow2 size=67108864 backing_file=test.qcow2
>> backing_fmt=qcow2 encryption=off cluster_size=65536
>> lazy_refcounts=off refcount_bits=16 {"return": {}}
>> {'execute':'eject','arguments':{'device':'drive0'}} {"error":
>> {"class": "GenericError", "desc": "Node 'drive0' is busy: block
>> device is in use by block job: backup"}}
>>
>> So... Nobody does it, but apparently nobody has to because you
>> cannot eject (to be more specific: use blockdev-remove-medium) a
>> BDS from a BB while a block job is running on the BDS.
>
> If you test it with all jobs, then it's okay. It's a regression, but
> not introduced by your patch and apparently nobody noticed.
>
> Even if nobody noticed, I wonder if this "Node 'foo' is busy" kind of
> error deserves its own ErrorClass. Eric, what do you think?Needing a unique ErrorClass is only important if we expect a client (libvirt) would behave differently based on that error class (clients are not allowed to parse the error message). But what is the scenario that we are trying to test here, rewritten in terms of libvirt API commands? Should libvirt behave any differently because a blockjob was running than for any other failure, if the end result is still that libvirt can't eject or hot-unplug the disk because of a failure? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
