Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionFederico Simoncelli
2012-05-07 11:39:58 UTC
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).
> 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 3Federico Simoncelli
2012-05-07 13:51:50 UTC
(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?
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.
Comment 13Federico Simoncelli
2012-09-20 08:53:45 UTC