Hide Forgot
Description of problem: When trying to convert a VMware OVA guest to libvirt/KVM, the following error happens: # LIBGUESTFS_BACKEND=direct virt-v2v -i ova ./hostname.ova -on hostname -o libvirt -os default -of qcow2 [ 0.0] Opening the source -i ova ./hostname.ova [ 1.0] Creating an overlay to protect the source from being modified [ 1.0] Opening the overlay [ 3.0] Initializing the target -o libvirt -os default [ 3.0] Inspecting the overlay virt-v2v: error: libguestfs error: aug_get: aug_get: /files/etc/fstab/1/opt: Too many matches for path expression: There are 2 nodes matching /files/etc/fstab/1/opt If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] (using workaround from https://access.redhat.com/solutions/2110391) Version-Release number of selected component (if applicable): libguestfs-1.28.1 libguestfs-tools-1.28.1 libguestfs-tools-c-1.28.1 libguestfs-winsupport-7.2 libvirt-1.2.17 libvirt-client-1.2.17 libvirt-daemon-1.2.17 libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-interface libvirt-daemon-driver-lxc-1.2.17 libvirt-daemon-driver-network-1.2.17 libvirt-daemon-driver-nodedev-1.2.17 libvirt-daemon-driver-nwfilter-1.2.17 libvirt-daemon-driver-qemu-1.2.17 libvirt-daemon-driver-secret-1.2.17 libvirt-daemon-driver-storage-1.2.17 libvirt-daemon-kvm-1.2.17 libvirt-python-1.2.17 qemu-img-1.5.3 qemu-kvm-common-1.5.3 qemu-kvm-tools-1.5.3 Additional info: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1615337
Please attach the complete virt-v2v -v -x output.
Actually forget that, this is fixed upstream already: https://github.com/libguestfs/libguestfs/commit/738c3bf4fdce569858369b2d2ce3879bf4b75f50
I can reproduce this bug with below builds: virt-v2v-1.32.7-3.el7_3.2.x86_64 libguestfs-1.32.7-3.el7_3.2.x86_64 libvirt-2.0.0-10.el7_3.4.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 Reproduce steps: 1.Prepare a linux guest on ESXi6.0 host and add below to /etc/fatab /dev/sda4 /home btrfs rw,user,subvol=foo 0 0 2.Use virt-v2v convert this guest to kvm # virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 [ 1.2] Creating an overlay to protect the source from being modified [ 1.9] Initializing the target -o libvirt -os default [ 1.9] Opening the overlay [ 14.8] Inspecting the overlay virt-v2v: error: libguestfs error: aug_get: aug_get: /files/etc/fstab/8/opt: Too many matches for path expression: There are 3 nodes matching /files/etc/fstab/8/opt If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...]
Verify the bug with builds: virt-v2v-1.36.1-1.el7.x86_64 libguestfs-1.36.1-1.el7.x86_64 libvirt-3.1.0-1.el7.x86_64 qemu-kvm-1.5.3-132.el7.x86_64 Steps: Scenario1: 1.Prepare a linux guest on ESXi6.0 host and add below to /etc/fatab /dev/sda4 /home btrfs rw,user,subvol 0 0 2.Use virt-v2v convert this guest to kvm, but the conversion is failed with below error, details pls refer to virt-v2v-1.36.1-1.log # virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 [ 1.2] Creating an overlay to protect the source from being modified [ 1.8] Initializing the target -o libvirt -os default [ 1.8] Opening the overlay [ 14.4] Inspecting the overlay virt-v2v: error: libguestfs error: aug_get: no matching node If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Scenario2: 1.Prepare a linux guest on ESXi6.0 host and add below to /etc/fatab /dev/sda4 /home btrfs rw,user,subvol=foo 0 0 2.Use virt-v2v convert this guest to kvm, the conversion can be finished but with warning # virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 mxie-rhel6.8 [ 1.3] Creating an overlay to protect the source from being modified [ 1.9] Initializing the target -o libvirt -os default [ 1.9] Opening the overlay [ 14.3] Inspecting the overlay virt-v2v: warning: mount: mount_stub: btrfsvol:/dev/sda4/foo: expecting a btrfs volume (ignored) [ 99.8] Checking for sufficient free disk space in the guest [ 99.8] Estimating space required on target for each disk [ 99.8] Converting Red Hat Enterprise Linux Server release 6.8 (Santiago) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 786.2] Mapping filesystem data to avoid copying unused and blank areas [ 787.4] Closing the overlay [ 787.5] Checking if the guest needs BIOS or UEFI to boot [ 787.5] Assigning disks to buses [ 787.5] Copying disk 1/1 to /var/lib/libvirt/images/mxie-rhel6.8-sda (raw) (100.00/100%) [ 936.4] Creating output metadata Pool default refreshed Domain mxie-rhel6.8 defined from /tmp/v2vlibvirtc26e53.xml [ 936.5] Finishing off Hi rjones, Could you help to see scenario1, why the conversion will be failed when not set subvol=foo in guest's /etc/fstab? pls also help see the warning in scenario2, whether the warning is accepted? Thanks
Created attachment 1261074 [details] virt-v2v-1.36.1-1.log
> /dev/sda4 /home btrfs rw,user,subvol 0 0 is incorrect syntax (it should always be subvol=PATH), so virt-v2v is entitled to fail on this. The error message (from lib/inspect-fs-unix.c:check_fstab) isn't that great, but with the virt-v2v -v -x output it would be trivial to see why it's failing so debugging this wouldn't be too hard.
Thanks for Richard's explanation, I just got the meaning of the line "/dev/sda4 /home btrfs rw,user,subvol=foo 0 0" Verify the bug with builds again: virt-v2v-1.36.2-1.el7.x86_64 libguestfs-1.36.2-1.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 Steps: 1.Install a rhel7 guest and configure the /home as a single partition and device type is btrfs 2.Check the /etc/fstab after finishing os installation #cat fstab .... UUID=b138e4bc-c35c-4917-976a-a00135b3d3e1 / ext4 defaults 1 1 UUID=23d0f88f-a199-418d-9e68-cfd9ad35b332 /home btrfs subvol=home 0 0 UUID=5ead36b0-9556-49c3-81a1-01b7f560126f swap swap defaults 0 0 3.Because /home is mounted by /dev/sda2, add below line into /etc/fstab /dev/sda2 /home btrfs rw,root,subvol=foo 0 0 4.Guest could rebooted normally after editting /etc/fstab 5.Power off the guest and then using virt-v2v convert the guest to rhvm,the conversion could be finished but with warning # virt-v2v rhel7.3 -o rhv -os 10.73.131.93:/home/nfs_export -on foo [ 0.0] Opening the source -i libvirt rhel7.3 [ 0.0] Creating an overlay to protect the source from being modified [ 0.2] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 0.4] Opening the overlay [ 15.4] Inspecting the overlay virt-v2v: warning: mount: /dev/sda2 on /home (options: ''): mount: mount(2) failed: No such file or directory (ignored) [ 32.3] Checking for sufficient free disk space in the guest [ 32.3] Estimating space required on target for each disk [ 32.3] Converting Red Hat Enterprise Linux Server 7.3 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 105.6] Mapping filesystem data to avoid copying unused and blank areas [ 105.7] Closing the overlay [ 105.8] Checking if the guest needs BIOS or UEFI to boot [ 105.8] Assigning disks to buses [ 105.8] Copying disk 1/1 to /tmp/v2v.hUiFiT/165c1942-70e7-4691-aa63-9184a0569bf2/images/085112d2-9901-4a4a-8da3-9f36a2b5ea18/b2c6f33f-a866-42c3-8fc6-b273531f07fa (qcow2) (100.00/100%) [ 538.4] Creating output metadata [ 538.5] Finishing off 6.Import the guest from export domain to data domain, power on the guest and checkpoints of guest are passed Hi rjones, Could you pls help check whether verify steps are enough and warning of conversion is correct? Thanks
Looks good to me.
According to comment 9 and comment 10, move the bug from ON_QA to VERIFIED
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, 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-2017:2023