Re: [Qemu-block] [PATCH v2 3/9] blockjob: Don't set iostatus of target

[Eric Blake]

On 05/06/2016 07:31 AM, Kevin Wolf wrote:
>>
>> Maybe I need to take that back. Using e.g. blockdev-backup, you can
>> indeed see the target in query-block.
>>

>> Where mnt is a file system and test.qcow2 is large enough such that an
>> ENOSPC will occur.
> 
> Hm... Let's pretend we didn't notice. In fact, I don't think this
> behaviour is documented and it also doesn't make a lot of sense.
> 
> I would be surprised if libvirt made use of it, as there is still the
> job iostatus which works in drive-* cases, too.
> 
> (Eric?)
> 
>> Before this patch, you can see "io-status": "nospace" in query-block for
>> dst. After it, it says "io-status": "ok", and after the next it doesn't
>> say anything about the status at all anymore.

Here's what libvirt does with "io-status":

qemuMonitorJSONGetBlockInfo():
        /* Missing io-status indicates no error */
        if ((status = virJSONValueObjectGetString(dev, "io-status"))) {
            info->io_status = qemuMonitorBlockIOStatusToError(status);
            if (info->io_status < 0)
                goto cleanup;
        }

Then it feeds info->io_status into qemuDomainGetDiskErrors().

However, I'm not sure I know the full context of your question - is
io-status still available on the primary BDS, and we are only deleting
it from a secondary spot used only during a job? I think libvirt is
currently only checking the status of the BDS (ENOSPC when the primary
runs out of room), not what happens during a block job.  In fact,
libvirt does not yet use 'blockdev-backup' at all, let alone
blockdev-backup with 'on-target-error':'enospc' (it should, but that's a
story for another day).

> 
> Simply letting the field disappear sounds like a nice solution.

So at first glance, I think we're okay here, dropping io-status from the
block job from this location and instead exposing it from a more natural
spot in QMP.  And in the worst case, we can use introspection to learn
which of two spots exposes the information, if libvirt is trying to be
portable to 2.6 and 2.7 at the same time.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature