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.
Description of problem:
libvirt did not do storage image pre-creation on the target host when doing storage migration
Version-Release number of selected component (if applicable):
libvirt-8.7.0-1.el9.x86_64
qemu-kvm-7.1.0-1.el9.x86_64
How reproducible:
100%
Steps to Reproduce:
1.Prepare a pool with the same path both on source and target host:
#virsh pool-list
Name State Autostart
--------------------------------
default active yes
#virsh pool-dumpxml default
<pool type='dir'>
<name>default</name>
<uuid>c98f3a9d-07a3-4447-bb0d-95d4deed55fc</uuid>
<capacity unit='bytes'>75125227520</capacity>
<allocation unit='bytes'>34892738560</allocation>
<available unit='bytes'>40232488960</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0711</mode>
<owner>0</owner>
<group>0</group>
<label>system_u:object_r:virt_image_t:s0</label>
</permissions>
</target>
</pool>
2.Start a guest with the images in the pool dir:
#virsh start avocado-vt-vm1
# virsh domblklist avocado-vt-vm1
Target Source
--------------------------------------------------------
vda /var/lib/libvirt/images/jeos-27-x86_64.qcow2
3.Do storage migration:
# virsh migrate avocado-vt-vm1 qemu+ssh://**.**.com/system --live --verbose --copy-storage-all
error: Path '/var/lib/libvirt/images/jeos-27-x86_64.qcow2' is not accessible: No such file or directory
Actual results:
Migration failed because libvirt did not pre-create storage image on the target host.
Expected results:
Migration should complete successfully.
Additional info:
1.Can not reproduce with libvirt-8.5.0-6.el9.x86_64 qemu-kvm-7.0.0-12.el9.x86_64.
This should be the same root cause as https://bugzilla.redhat.com/show_bug.cgi?id=2125111
In that BZ it seems that the storage was pre-created by the user, but another wrong code path was hit.
Should be fixed by:
commit 83ffeae75a0dfe8077d5e98f8a48615c62db0284
Author: Peter Krempa <pkrempa>
Date: Thu Sep 8 11:55:08 2022 +0200
qemu: migration: Fix setup of non-shared storage migration in qemuMigrationSrcBeginPhase
In commit 6111b2352242e9 removing pre-blockdev code paths I've
improperly refactored the setup of non-shared storage migration.
Specifically the code checking that there are disks and setting up the
NBD data in the migration cookie was originally outside of the loop
checking the user provided list of specific disks to migrate, but became
part of the block as it was not un-indented when a higher level block
was being removed.
The above caused that if non-shared storage migration is requested, but
the user doesn't provide the list of disks to migrate (thus implying to
migrate every appropriate disk) the code doesn't actually setup the
migration and then later on falls back to the old-style migration which
no longer works with blockdev.
Move the check that there's anything to migrate out of the
'nmigrate_disks' block.
Fixes: 6111b2352242e93c6d2c29f9549d596ed1056ce5
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2125111
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/373
Signed-off-by: Peter Krempa <pkrempa>
Reviewed-by: Ján Tomko <jtomko>
v8.7.0-93-g83ffeae75a
I'll keep this one open for now to see whether it's properly fixed too.
You can verify that the migration code still works properly by adding '--migrate-disks vda'. This works around the broken setup code and the rest of the migration should work fine.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (libvirt bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:2171
Description of problem: libvirt did not do storage image pre-creation on the target host when doing storage migration Version-Release number of selected component (if applicable): libvirt-8.7.0-1.el9.x86_64 qemu-kvm-7.1.0-1.el9.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a pool with the same path both on source and target host: #virsh pool-list Name State Autostart -------------------------------- default active yes #virsh pool-dumpxml default <pool type='dir'> <name>default</name> <uuid>c98f3a9d-07a3-4447-bb0d-95d4deed55fc</uuid> <capacity unit='bytes'>75125227520</capacity> <allocation unit='bytes'>34892738560</allocation> <available unit='bytes'>40232488960</available> <source> </source> <target> <path>/var/lib/libvirt/images</path> <permissions> <mode>0711</mode> <owner>0</owner> <group>0</group> <label>system_u:object_r:virt_image_t:s0</label> </permissions> </target> </pool> 2.Start a guest with the images in the pool dir: #virsh start avocado-vt-vm1 # virsh domblklist avocado-vt-vm1 Target Source -------------------------------------------------------- vda /var/lib/libvirt/images/jeos-27-x86_64.qcow2 3.Do storage migration: # virsh migrate avocado-vt-vm1 qemu+ssh://**.**.com/system --live --verbose --copy-storage-all error: Path '/var/lib/libvirt/images/jeos-27-x86_64.qcow2' is not accessible: No such file or directory Actual results: Migration failed because libvirt did not pre-create storage image on the target host. Expected results: Migration should complete successfully. Additional info: 1.Can not reproduce with libvirt-8.5.0-6.el9.x86_64 qemu-kvm-7.0.0-12.el9.x86_64.