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.
Volume creation can take a long time. Attempting to delete a volume which is still being created returns an error. It is not currently possible to work round this, for example with an API to cancel the creation process.
This impacts V2V. V2V removes all inconsistent volumes if the conversion process fails or is interrupted. This cleanup will fail if the user hits Ctrl-C during a long-running volume creation, because the volume cannot be deleted. This will cause subsequent V2V conversions to fail because the volume already exists.
This bug was not selected to be addressed in Red Hat Enterprise Linux 6. We will look at it again within the Red Hat Enterprise Linux 7 product.
Comment 12Michal Privoznik
2014-05-29 13:48:43 UTC
Fixed upstream:
commit eb54426659888bf04fdef409afaccf8c0fd199a0
Author: Michal Privoznik <mprivozn>
AuthorDate: Wed Apr 16 15:16:20 2014 +0200
Commit: Michal Privoznik <mprivozn>
CommitDate: Tue May 6 10:24:44 2014 +0200
storageVolCreateXMLFrom: Allow multiple accesses to origvol
When creating a new volume, it is possible to copy data into it from
another already existing volume (referred to as @origvol). Obviously,
the read-only access to @origvol is required, which is thread safe
(probably not performance-wise though). However, with current code
both @newvol and @origvol are marked as building for the time of
copying data from the @origvol to @newvol. The rationale behind
is to disallow some operations on both @origvol and @newvol, e.g.
vol-wipe, vol-delete, vol-download. While it makes sense to not allow
such operations on partly copied mirror, but it doesn't make sense to
disallow vol-create or vol-download on the source (@origvol).
Signed-off-by: Michal Privoznik <mprivozn>
v1.2.4-18-geb54426 (so you have to use the v1.2.5-rc1~111 release)
Comment 18Richard W.M. Jones
2016-02-17 10:33:40 UTC
I'm closing this. The fix was originally requested for virt-v2v,
but the new version of virt-v2v does not use libvirt for volume
creation, hence this is no longer a problem.