Red Hat Bugzilla – Bug 1451665
RFE: Virt-v2v can't convert the guest which has encrypted partition
Last modified: 2018-04-10 05:15:08 EDT
Created attachment 1279603 [details] virt-v2v-encrypted-guest.log Description of problem: Virt-v2v can't convert the guest which has encrypted partition Version-Release number of selected component (if applicable): virt-v2v-1.36.3-3.el7.x86_64 libguestfs-1.36.3-3.el7.x86_64 libvirt-3.2.0-5.el7.x86_64 qemu-kvm-1.5.3-137.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a linux guest which has encrypted partition on xen server and using virt-v2v can convert the encrypted guest but the conversion is failed. pls refer to attachment log # virt-v2v -ic xen+ssh://root@10.73.3.21 Auto-xen-rhel6.9-case13063 -of qcow2 -b default [ 0.0] Opening the source -i libvirt -ic xen+ssh://root@10.73.3.21 Auto-xen-rhel6.9-case13063 [ 0.7] Creating an overlay to protect the source from being modified [ 7.2] Initializing the target -o libvirt -os default [ 7.2] Opening the overlay [ 237.4] Inspecting the overlay virt-v2v: error: inspection could not detect the source guest (or physical machine). Assuming that you are running virt-v2v/virt-p2v on a source which is supported (and not, for example, a blank disk), then this should not happen. No root device found in this operating system image. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Actual results: As above description Expected results: Virt-v2v can convert encrypted guest Additional info:
Hi mxie, the guest of this test is the classic whole-disk LUKS encryption done by the Fedora/RHEL installer, right?
(In reply to Pino Toscano from comment #2) > Hi mxie, > > the guest of this test is the classic whole-disk LUKS encryption done by the > Fedora/RHEL installer, right? Hi Pino, Yes, pls refer to below partition info of the encrypted rhel6.9 guest which is installed on xen server #lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 14.7G 0 disk ├─xvda1 202:1 0 500M 0 part /boot └─xvda2 202:2 0 14.2G 0 part └─luks-6b952cdc-9d5b-426d-bd0c-1ba16e00b4eb (dm-0) 253:0 0 14.2G 0 crypt ├─VolGroup-lv_root (dm-1) 253:1 0 12.7G 0 lvm / └─VolGroup-lv_swap (dm-2) 253:2 0 1.5G 0 lvm [SWAP] sr0 11:0 1 1024M 0 rom
Fixed with https://github.com/libguestfs/libguestfs/commit/7e6c16f1e7698317991b875f2d7ab3ce9e94c8bb which is in libguestfs >= 1.37.15.
Created attachment 1338167 [details] v2v-exit.log
To verify it with below builds: libvirt-3.8.0-1.el7.x86_64- virt-v2v-1.36.10-1.el7.x86_64 libguestfs-1.36.10-1.el7.x86_64 qemu-kvm-rhev-2.10.0-3.el7.x86_64 Step； 1.Using virt-v2v to convert the guest as below. # virt-v2v -ic xen+ssh://root@10.73.3.21 6.9-encrypted -of raw [ 0.0] Opening the source -i libvirt -ic xen+ssh://root@10.73.3.21 6.9-encrypted [ 0.5] Creating an overlay to protect the source from being modified [ 1.0] Initializing the target -o libvirt -os default [ 1.1] Opening the overlay Enter key or passphrase ("/dev/sda2"): [ 7.3] Inspecting the overlay [ 17.0] Checking for sufficient free disk space in the guest [ 17.0] Estimating space required on target for each disk [ 17.0] Converting Red Hat Enterprise Linux Server release 6.9 (Santiago) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 78.2] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/VolGroup/lv_root failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 78.3] Closing the overlay [ 78.4] Checking if the guest needs BIOS or UEFI to boot [ 78.4] Assigning disks to buses [ 78.4] Copying disk 1/1 to /var/lib/libvirt/images/6.9-encrypted-sda (raw) (100.00/100%) [ 258.8] Creating output metadata Pool default refreshed Domain 6.9-encrypted defined from /tmp/v2vlibvirt3254f2.xml [ 261.2] Finishing off 2.After conversion,boot into the system and checkpoints all passed. Sorry for comment6,maybe that guest exist some problem.Thanks for your reply. So, the bug has fixed ,move the bug status 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-2018:0677