Red Hat Bugzilla – Bug 819485
[NFR] libvirt: Returning the watermark for all the images opened for writing
Last modified: 2014-10-28 10:48:28 EDT
Description of problem:
At the moment during the streaming+mirroring it is impossible to poll the wr_highest_offset of the destination image.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start qemu-kvm with a qcow2 disk attached
2. Start migrating (streaming+mirroring) the disk to a new qcow2 image
Currently there is no way to monitor the watermark (wr_highest_offset) of the mirrored image.
VDSM needs a way to monitor the watermark to extend the LVs on block domains.
The preferred way to fetch the watermark is with the current blockstats (wr_highest_offset) and the qemu-kvm process should return the highest offset between the source image and the destination image.
There is a special case when the format of the destination is different from the source (qcow2/raw) and at least one of the two is raw. In such case the wr_highest_offset of a raw device has no meaning and should be discarded (returning always the wr_highest_offset of the qcow2 image).
> The preferred way to fetch the watermark is with the current blockstats
> (wr_highest_offset) and the qemu-kvm process should return the highest offset
> between the source image and the destination image.
This could be done by libvirt. qemu-kvm would return the value in info block-job.
(In reply to comment #2)
> > The preferred way to fetch the watermark is with the current blockstats
> > (wr_highest_offset) and the qemu-kvm process should return the highest offset
> > between the source image and the destination image.
> This could be done by libvirt. qemu-kvm would return the value in info
Eric what do you think?
If I understand correctly, you are proposing new output in 'query-block-jobs', and requesting that libvirt expose this new information via virDomainBlockJobInfo().
Alas, virDomainBlockJobInfoPtr is a poorly-designed API - it has a fixed-size struct, so there is no way to directly cram any additional information into the RPC call currently used for virDomainBlockJobInfo(). That said, at least it has a flags parameter; I could do a hack where the use of a non-zero flags says to reuse existing members of the struct for different statistics (that is, instead of reporting cur/end, we could say that the use of a flag reports the watermark stat instead).
Another possibility is to use virDomainBlockStatsFlags(), which is a properly-designed API flexible enough to add new parameters. It would be feasible to define new block stats corresponding to any information associated with a block job, where the stat is normally 0 but during a block job can be queried from the job.
So, if the question is whether we can support this using just the RHEL 6.3 API, I think the answer is yes. But we also have to consider that this is very late in the RHEL 6.3 cycle; how badly do you need the information and by when?
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
The dependent bug 822165 is flagged for 6.5, so I'm moving this bug too.
But the feature overall was superseded by bug 844627, so it could even be WONTFIX.
Updating the title according to:
Discussed this with Andrew Cathrow: we're targeting this feature at RHEL7.x, so closing this as WONTFIX in RHEL6.
Clone for RHEL7 is Bug 1041569