Bug 819485 - [NFR] libvirt: Returning the watermark for all the images opened for writing
[NFR] libvirt: Returning the watermark for all the images opened for writing
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Eric Blake
Virtualization Bugs
:
Depends On: 822165 1041564
Blocks: 1041569 1158094
  Show dependency treegraph
 
Reported: 2012-05-07 07:39 EDT by Federico Simoncelli
Modified: 2014-10-28 10:48 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 822165 1041569 (view as bug list)
Environment:
Last Closed: 2013-12-12 12:39:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Federico Simoncelli 2012-05-07 07:39:58 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):
qemu-kvm-rhev-0.12.1.2-2.288.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Start qemu-kvm with a qcow2 disk attached
2. Start migrating (streaming+mirroring) the disk to a new qcow2 image

Actual results:
Currently there is no way to monitor the watermark (wr_highest_offset) of the mirrored image.

Expected results:
VDSM needs a way to monitor the watermark to extend the LVs on block domains. 

Additional info:
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).
Comment 2 Paolo Bonzini 2012-05-07 08:06:42 EDT
> 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.
Comment 3 Federico Simoncelli 2012-05-07 09:51:50 EDT
(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
> block-job.

Eric what do you think?
Comment 4 Eric Blake 2012-05-09 12:23:46 EDT
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?
Comment 11 Suzanne Yeghiayan 2012-05-18 16:57:54 EDT
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.
Comment 12 Paolo Bonzini 2012-09-03 10:50:56 EDT
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.
Comment 13 Federico Simoncelli 2012-09-20 04:53:45 EDT
Updating the title according to:

https://bugzilla.redhat.com/show_bug.cgi?id=822165#c8
Comment 15 Ademar Reis 2013-12-12 12:39:45 EST
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

Note You need to log in before you can comment on or make changes to this bug.