Hide Forgot
+++ This bug was initially created as a clone of Bug #1362497 +++ Description of problem: Currently virt-v2v can import only RPM based linux guests. When attempting to import Ubuntu guest the import ends with an error: virt-v2v: error: virt-v2v is unable to convert this guest type(linux/ubuntu)
Verify the bug with builds 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 libguestfs-winsupport-7.2-2.el7.x86_64 virtio-win-1.9.0-3.el7.noarch Steps: Check debian and ubuntu info in virt-v2v man page #man virt-v2v .... DEBIAN AND UBUNTU "warning: could not determine a way to update the configuration of Grub2" Currently, virt-v2v has no way to set the default kernel in Debian and Ubuntu guests using GRUB 2 as bootloader. This means that virt-v2v will not change the default kernel used for booting, even in case it is not the best kernel available on the guest. A recommended procedure is, before using virt-v2v, to check that the boot kernel is the best kernel available in the guest (for example by making sure the guest is up-to-date). .... Result:there will be warning: could not determine a way to update the configuration of Grub2 during converting debian and ubuntu guest by virt-v2v Grub2' For debian guest: Scenario1: 1.1 Prepare a debian guest and convert this guest to from kvm to rhv by virt-v2v # virt-v2v debian6 -o rhev -os 10.73.131.93:/home/nfs_export [ 0.0] Opening the source -i libvirt debian6 [ 0.0] Creating an overlay to protect the source from being modified [ 0.3] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 0.4] Opening the overlay [ 2.7] Inspecting the overlay [ 3.6] Checking for sufficient free disk space in the guest [ 3.6] Estimating space required on target for each disk [ 3.6] Converting 6.0.4 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". You may have to fix this entry manually after conversion. virt-v2v: This guest has virtio drivers installed. [ 12.3] Mapping filesystem data to avoid copying unused and blank areas [ 12.5] Closing the overlay [ 13.0] Checking if the guest needs BIOS or UEFI to boot [ 13.0] Assigning disks to buses [ 13.0] Copying disk 1/1 to /tmp/v2v.frRPNZ/165c1942-70e7-4691-aa63-9184a0569bf2/images/ebe5206a-8121-4736-aa86-a5aa58ab415c/888e2872-ed2f-42e1-a112-b1f515894dab (qcow2) (100.00/100%) [ 323.0] Creating output metadata [ 323.1] Finishing off Result: There is another virt-v2v warning "could not determine a way to update the configuration of Grub2 " during conversion 1.2.Check points for debian guest at rhv as below,pls refer to screenshot 'debian-rhv' and log 'debian-kvm-to-rhv' 1.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_console 2263 0 [permanent] virtio_net 10493 0 virtio_blk 4161 0 virtio_pci 5495 0 virtio_ring 3242 1 virtio_pci virtio 3277 4 virtio_console,virtio_net,virtio_blk,virtio_pci Result: Debian guest doesn't have virtio_balloon module but have virtio_console 1.2.2 device.map has been updated to vda, (hd0) /dev/vda 1.2.3 could get ip nomarlly, # ip a list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:98:8a:53 brd ff:ff:ff:ff:ff:ff inet 10.66.145.149/24 brd 10.66.147.255 scope global dynamic eth0 valid_lft 3049sec preferred_lft 3049sec inet6 fe80::5054：ff:fe7c:847c/64 scope link valid_lft forever preferred_lft fo 1.2.4 Check qxl driver in guest, #cat /var/log/Xorg.0.log |grep qxl nothing #lspci -v |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev 04)(prog-if 00 [VGA controller]) Result：Can‘t find qxl driver in debian guest Hi rjones， Pls help to check the result of step1.1, step1.2.1 and step1.2.4, thanks~ Scenario2: 2.1 Convert debian guest to from kvm to openstack by virt-v2v # virt-v2v debian6 -o glance [ 0.0] Opening the source -i libvirt debian6 [ 0.0] Creating an overlay to protect the source from being modified [ 0.3] Initializing the target -o glance [ 1.0] Opening the overlay [ 2.5] Inspecting the overlay [ 9.9] Checking for sufficient free disk space in the guest [ 9.9] Estimating space required on target for each disk [ 9.9] Converting 6.0.4 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". You may have to fix this entry manually after conversion. virt-v2v: This guest has virtio drivers installed. [ 17.6] Mapping filesystem data to avoid copying unused and blank areas [ 18.1] Closing the overlay [ 18.8] Checking if the guest needs BIOS or UEFI to boot [ 18.8] Assigning disks to buses [ 18.8] Copying disk 1/1 to /var/tmp/glance.g8uCIH/sda (qcow2) (100.00/100%) [ 151.5] Creating output metadata +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | architecture | x86_64 | | checksum | c3b6280a2f4eac6cf63317262fd06532 | | container_format | bare | | created_at | 2017-03-12T14:32:37Z | | disk_format | qcow2 | | hw_disk_bus | virtio | | hw_video_model | qxl | | hw_vif_model | virtio | | hypervisor_type | kvm | | id | c29905a5-9c60-4109-b178-4e156a32ee83 | | min_disk | 0 | | min_ram | 512 | | name | debian6 | | os_distro | debian | | os_type | linux | | os_version | 6 | | owner | 6c4dac53186d44fcbac29d3f3f575125 | | protected | False | | size | 3400335360 | | status | active | | tags | [] | | updated_at | 2017-03-12T14:39:00Z | | virtual_size | None | | visibility | private | | vm_mode | hvm | +------------------+--------------------------------------+ [ 535.4] Finishing off 2.2 Check points for debian guest at openstack, the most result of checkpoints are same as step1.2 of scenario1 except step1.2.1 2.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_balloon 2961 0 virtio_net 10573 0 virtio_blk 4209 0 virtio_pci 5495 0 virtio_ring 3258 1 virtio_pci virtio 3309 4 virtio_ballon,virtio_net,virtio_blk,virtio_pci Result: Debian guest has virtio_balloon module but doesn't have virtio_console, I think this result is correct Scenario3: 3.1 Convert debian guest from vmware to kvm by virt-v2v, # virt-v2v -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 debian6 -on esx5.5-debian6 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 debian6 [ 1.8] Creating an overlay to protect the source from being modified [ 2.3] Initializing the target -o libvirt -os default [ 2.3] Opening the overlay [ 10.0] Inspecting the overlay [ 18.0] Checking for sufficient free disk space in the guest [ 18.0] Estimating space required on target for each disk [ 18.0] Converting 6.0.4 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". You may have to fix this entry manually after conversion. virt-v2v: This guest has virtio drivers installed. [ 260.8] Mapping filesystem data to avoid copying unused and blank areas [ 292.9] Closing the overlay [ 292.9] Checking if the guest needs BIOS or UEFI to boot [ 292.9] Assigning disks to buses [ 292.9] Copying disk 1/1 to /var/lib/libvirt/images/esx5.5-debian6-sda (raw) (100.00/100%) [1822.2] Creating output metadata Pool default refreshed Domain esx5.5-debian6 defined from /tmp/v2vlibvirt066dba.xml [1822.4] Finishing off 3.2 Check points for debian guest at kvm,most result of checkpoints are same as step1.2 of scenario1 except step1.2.1, step1.2.2, 3.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_ballon 2961 0 virtio_net 10573 0 virtio_blk 4209 0 virtio_pci 5495 0 virtio_ring 3258 1 virtio_pci virtio 3309 4 virtio_ballon,virtio_net,virtio_blk,virtio_pci 3.2.2 Check device.map and disk type in guest #cat /boot/grub/device.map (hd0) /dev/sda #df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 16G 3.2G 12G 23% / ... Result:device.map wasn't updated to vda but disk type is vda, details pls refer to log"virt-v2v-debain-from-vmware" Hi rjones, Pls help check the problem of step3.2.2, thanks! For ubuntu guest: Scenario1 1.1 Prepare a Ubuntu guest and convert this guest to from kvm to rhv by virt-v2v # virt-v2v ubuntu16.04 -o rhev -os 10.73.131.93:/home/nfs_export -of qcow2 [ 0.0] Opening the source -i libvirt ubuntu16.04 [ 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 [ 1.5] Inspecting the overlay [ 2.6] Checking for sufficient free disk space in the guest [ 2.6] Estimating space required on target for each disk [ 2.6] Converting Ubuntu 16.04.1 LTS to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 19.6] Mapping filesystem data to avoid copying unused and blank areas [ 20.8] Closing the overlay [ 21.0] Checking if the guest needs BIOS or UEFI to boot [ 21.0] Assigning disks to buses [ 21.0] Copying disk 1/1 to /tmp/v2v.OugLnl/165c1942-70e7-4691-aa63-9184a0569bf2/images/bc0803c5-d17f-4122-b472-27c2a220bbd3/1945e895-87a1-4ade-ae10-8b8289057c04 (qcow2) (100.00/100%) [ 207.5] Creating output metadata [ 207.8] Finishing off 1.2 Check points for ubuntu guest at rhv as below,details pls refer to screenshot"ubuntu-rhv" and log 'virt-v2v-ubuntu-to-rhv.log' 1.2.1 Check virtio driver in guest # lsmod |grep virtio virtio_scsi 20480 0 1.2.2 Could get ip nomarlly # ip a list .... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:98:8a:53 brd ff:ff:ff:ff:ff:ff inet 10.66.145.58/24 brd 10.66.147.255 scope global dynamic eth0 valid_lft 3049sec preferred_lft 3049sec inet6 fe80::5054：ff:fe7c:847c/64 scope link valid_lft forever preferred_lft fo .... 1.2.3 there is no device.map in guest but disk has been update to vda, #cat /boot/grub/device.map nothing #lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 1 15G 0 disk ├─vda1 253:1 0 487M 0 part /boot ├─vda2 253:2 0 1K 0 part ├─vda5 253:5 0 14.5G 0 part ├─ubuntu-vg-root 252:0 0 13.5G 0 lvm / └─ubuntu-vg-swap_1 252:1 0 1G 0 lvm [swap] 1.2.4 Check qxl driver in guest, #lspci -v |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc.QXL paravirtual graphic card (rev 04)(prog-if 00 [VGA controller]) Hi rjones， Pls help to check the result of step1.2.1 and step1.2.3,thanks~ Scenario2: 2.1 Convert ubuntu guest to openstack by virt-v2v # virt-v2v ubuntu16.04 -o glance [ 0.0] Opening the source -i libvirt ubuntu16.04 [ 0.0] Creating an overlay to protect the source from being modified [ 0.3] Initializing the target -o glance [ 1.5] Opening the overlay [ 27.8] Inspecting the overlay [ 29.2] Checking for sufficient free disk space in the guest [ 29.2] Estimating space required on target for each disk [ 29.2] Converting Ubuntu 16.04.1 LTS to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 63.2] Mapping filesystem data to avoid copying unused and blank areas [ 67.7] Closing the overlay [ 67.9] Checking if the guest needs BIOS or UEFI to boot [ 67.9] Assigning disks to buses [ 67.9] Copying disk 1/1 to /var/tmp/glance.njS7bX/sda (qcow2) (100.00/100%) [ 149.9] Creating output metadata +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | architecture | x86_64 | | checksum | 1e391a3149204172ed23db2ea52e44fa | | container_format | bare | | created_at | 2017-03-12T14:32:07Z | | disk_format | qcow2 | | hw_disk_bus | virtio | | hw_video_model | qxl | | hw_vif_model | virtio | | hypervisor_type | kvm | | id | 5ffca539-ab89-44c2-83fa-97755be1303a | | min_disk | 0 | | min_ram | 1024 | | name | ubuntu16.04 | | os_distro | ubuntu | | os_type | linux | | os_version | 16.4 | | owner | 6c4dac53186d44fcbac29d3f3f575125 | | protected | False | | size | 1328873472 | | status | active | | tags | [] | | updated_at | 2017-03-12T14:35:48Z | | virtual_size | None | | visibility | private | | vm_mode | hvm | +------------------+--------------------------------------+ [ 373.9] Finishing off 2.2 Check points for unbuntu guest on openstack,the most result of checkpoints are same as step1.2 of scenario1 Scenario3: 3.1 Convert ubuntu guest from vmware to kvm by virt-v2v # virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 ubuntu16.04 -on esx6.0-ubuntu16.04 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 ubuntu16.04 [ 1.3] Creating an overlay to protect the source from being modified [ 2.0] Initializing the target -o libvirt -os default [ 2.0] Opening the overlay [ 14.5] Inspecting the overlay [ 24.3] Checking for sufficient free disk space in the guest [ 24.3] Estimating space required on target for each disk [ 24.3] Converting Ubuntu 16.04.1 LTS to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 401.9] Mapping filesystem data to avoid copying unused and blank areas [ 414.4] Closing the overlay [ 414.5] Checking if the guest needs BIOS or UEFI to boot [ 414.5] Assigning disks to buses [ 414.5] Copying disk 1/1 to /var/lib/libvirt/images/esx6.0-ubuntu16.04-sda (raw) (100.00/100%) [1202.3] Creating output metadata Pool default refreshed Domain esx6.0-ubuntu16.04 defined from /tmp/v2vlibvirt72d2d6.xml [1203.1] Finishing off 3.2 Check points for unbuntu after finishing v2v conversion, the most result of checkpoints are same as step1.2 of scenario1 except step1.2.2 3.2.1 Check virtio driver in guest # lsmod |grep virtio virtio_scsi 20480 0 3.2.2 Check network status in guest # ip a list .... 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc state DOWN group default qlen 1000 link/ether 00:50:56:b7:d6:8a brd ff:ff:ff:ff:ff:ff .... #cat etc/network/interfaces .... #The primary network interface auto ens160 .... Result: Because the NIC name of ip list is different with script of network interface, guest can't get ip normally after virt-v2v converting from vmware to kvm, details pls refer screenshot"ubuntu-from-vmware" and log"" Hi rjones, Pls help to check the problem of step3.2.2, thanks~
Created attachment 1262790 [details] debian-rhv
Created attachment 1262791 [details] debian-kvm-to-rhv.log
Created attachment 1262792 [details] virt-v2v-debian-from-vmware.log
Created attachment 1262793 [details] ubuntu-rhv
Created attachment 1262794 [details] virt-v2v-ubuntu-to-rhv.log
Created attachment 1262796 [details] ubuntu-from-vmware.png
Add guest version for comment 11 Ubuntu version: 16.04.1-server-x86_64 Debian version:6.0.4-amd64 Correct some mistake in comment 11 1.For debian guest -> scenario1 -> correct the result of step 1.1 Result: There is another virt-v2v warning "files/etc/fstab/4/spec references unknown device "scd"." during conversion 2.For ubuntu guest -> scenario1 -> add the result for step 1.2.1 Result: Only virtio_scsi module exists 3.For ubuntu guest -> scenario3 -> correct the result of step 3.2.2 Result: Because the NIC name of 'ip a list' is different with network interface of script, guest can't get ip normally after virt-v2v converting from vmware to kvm, details pls refer screenshot"ubuntu-from-vmware" and log"virt-v2v-ubuntu-from-vmware"
Created attachment 1262832 [details] virt-v2v-ubuntu-from-vmware.log
NEEDINFO -> Tomáš Golembiovský who is taking care of this feature.
(In reply to mxie from comment #11) > Verify the bug with builds > 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 > libguestfs-winsupport-7.2-2.el7.x86_64 > virtio-win-1.9.0-3.el7.noarch > > Steps: > Check debian and ubuntu info in virt-v2v man page > #man virt-v2v > .... > DEBIAN AND UBUNTU > "warning: could not determine a way to update the configuration of Grub2" > Currently, virt-v2v has no way to set the default kernel in Debian > and Ubuntu guests using GRUB 2 as > bootloader. This means that virt-v2v will not change the default > kernel used for booting, even in > case it is not the best kernel available on the guest. A recommended > procedure is, before using > virt-v2v, to check that the boot kernel is the best kernel available > in the guest (for example by > making sure the guest is up-to-date). > .... > > > Result:there will be warning: could not determine a way to update the > configuration of Grub2 during converting debian and ubuntu guest by virt-v2v > Grub2' On Debian 6+ there is GRUB 2 as default, so that is expected at the moment. Note this will not happen when the guest uses GRUB 1 (called also grub-legacy). > For debian guest: > > Scenario1: > 1.1 Prepare a debian guest and convert this guest to from kvm to rhv by > virt-v2v > # virt-v2v debian6 -o rhev -os 10.73.131.93:/home/nfs_export > [ 0.0] Opening the source -i libvirt debian6 > [ 0.0] Creating an overlay to protect the source from being modified > [ 0.3] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export > [ 0.4] Opening the overlay > [ 2.7] Inspecting the overlay > [ 3.6] Checking for sufficient free disk space in the guest > [ 3.6] Estimating space required on target for each disk > [ 3.6] Converting 6.0.4 to run on KVM > virt-v2v: warning: could not determine a way to update the configuration of > Grub2 > virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". > You may have to fix this entry manually after conversion. Can you please attach the /etc/fstab of the guest? > virt-v2v: This guest has virtio drivers installed. > [ 12.3] Mapping filesystem data to avoid copying unused and blank areas > [ 12.5] Closing the overlay > [ 13.0] Checking if the guest needs BIOS or UEFI to boot > [ 13.0] Assigning disks to buses > [ 13.0] Copying disk 1/1 to > /tmp/v2v.frRPNZ/165c1942-70e7-4691-aa63-9184a0569bf2/images/ebe5206a-8121- > 4736-aa86-a5aa58ab415c/888e2872-ed2f-42e1-a112-b1f515894dab (qcow2) > (100.00/100%) > [ 323.0] Creating output metadata > [ 323.1] Finishing off > > Result: > There is another virt-v2v warning "could not determine a way to update the > configuration of Grub2 " during conversion That's what is documented, yes. > 1.2.1 Check virtio drivers in guest > # lsmod |grep virtio > virtio_console 2263 0 [permanent] > virtio_net 10493 0 > virtio_blk 4161 0 > virtio_pci 5495 0 > virtio_ring 3242 1 virtio_pci > virtio 3277 4 > virtio_console,virtio_net,virtio_blk,virtio_pci > > Result: > Debian guest doesn't have virtio_balloon module but have virtio_console virt-v2v does not do anything with balloon devices in the guest, so most probably this comes from other sources. Considering the scenario 2.2.1 shows virtio-balloon, I wonder whether there's something missing on RHV side. Wwas virtio_balloon loaded when running the guest before the v2v operation? > 1.2.4 Check qxl driver in guest, > #cat /var/log/Xorg.0.log |grep qxl > nothing > #lspci -v |grep VGA > 00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev > 04)(prog-if 00 [VGA controller]) > > Result：Can‘t find qxl driver in debian guest Hmm... I guess whether setting the proper ostype in the <Description> tag of the OVF will improve the situation: right now, Debian guests will get a generic "OtherLinux". I will send a patch for this. > Scenario3: > [...] > 3.2.2 Check device.map and disk type in guest > #cat /boot/grub/device.map > (hd0) /dev/sda > #df -h > Filesystem Size Used Avail Use% Mounted on > /dev/vda1 16G 3.2G 12G 23% / > ... > > Result:device.map wasn't updated to vda but disk type is vda I see, we don't look for device.map in /boot/grub/ -- I will send a patch for this. , details pls > refer to log"virt-v2v-debain-from-vmware" > For ubuntu guest: > > Scenario1 > 1.1 Prepare a Ubuntu guest and convert this guest to from kvm to rhv by > virt-v2v > [..] > 1.2.1 Check virtio driver in guest > # lsmod |grep virtio > virtio_scsi 20480 0 In the Ubuntu kernels, some virtio features are compiled built-in in the kernel, and not as module: you can check by grepping for VIRTIO in the /boot/config-$kernel files, noticing there are more features as 'y' (instead of 'm'). Nevertheless, some of the issues of the RHV export described above for Debian guests should apply also in this case. > Scenario3: > 3.1 Convert ubuntu guest from vmware to kvm by virt-v2v > [...] > 3.2.2 Check network status in guest > # ip a list > .... > 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc state DOWN group > default qlen 1000 > link/ether 00:50:56:b7:d6:8a brd ff:ff:ff:ff:ff:ff > .... > > #cat etc/network/interfaces > .... > #The primary network interface > auto ens160 > .... > > Result: > Because the NIC name of ip list is different with script of network > interface, guest can't get ip normally after virt-v2v converting from vmware > to kvm I wonder whether something related (or even the same issue) of bug 1318922.
(In reply to Pino Toscano from comment #21) > (In reply to mxie from comment #11) > > For debian guest: > > Scenario1: > > 1.1 Prepare a debian guest and convert this guest to from kvm to rhv by > > virt-v2v > > # virt-v2v debian6 -o rhev -os 10.73.131.93:/home/nfs_export > > [ 0.0] Opening the source -i libvirt debian6 > > [ 0.0] Creating an overlay to protect the source from being modified > > [ 0.3] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export > > [ 0.4] Opening the overlay > > [ 2.7] Inspecting the overlay > > [ 3.6] Checking for sufficient free disk space in the guest > > [ 3.6] Estimating space required on target for each disk > > [ 3.6] Converting 6.0.4 to run on KVM > > virt-v2v: warning: could not determine a way to update the configuration of > > Grub2 > > virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". > > You may have to fix this entry manually after conversion. > > Can you please attach the /etc/fstab of the guest? Have attached the screenshot "fstab_debian" > > 1.2.1 Check virtio drivers in guest > > # lsmod |grep virtio > > virtio_console 2263 0 [permanent] > > virtio_net 10493 0 > > virtio_blk 4161 0 > > virtio_pci 5495 0 > > virtio_ring 3242 1 virtio_pci > > virtio 3277 4 > > virtio_console,virtio_net,virtio_blk,virtio_pci > > > > Result: > > Debian guest doesn't have virtio_balloon module but have virtio_console > > virt-v2v does not do anything with balloon devices in the guest, so most > probably this comes from other sources. Considering the scenario 2.2.1 > shows virtio-balloon, I wonder whether there's something missing on RHV > side. > > Wwas virtio_balloon loaded when running the guest before the v2v > operation? I check the related virtio module in original debian guest which is installed on qemu-kvm hypervisor, virtio_balloon and virtio_console both exists in original debian guest before doing v2v conversion. But virito_balloon will be removed when convert debian guest from kvm to rhv as scenario1 And virtio_console will be removed when convert the guest from kvm to openstack as scenario2 If the debian is installed on vmware host, there is no related balloon module in original debian guest, but the debian guest will include virtio_balloon module after v2v converting from vmware to kvm as scenario3 > > For ubuntu guest: > > > > Scenario1 > > 1.1 Prepare a Ubuntu guest and convert this guest to from kvm to rhv by > > virt-v2v > > [..] > > 1.2.1 Check virtio driver in guest > > # lsmod |grep virtio > > virtio_scsi 20480 0 > > In the Ubuntu kernels, some virtio features are compiled built-in in the > kernel, and not as module: you can check by grepping for VIRTIO in the > /boot/config-$kernel files, noticing there are more features as 'y' > (instead of 'm'). Nevertheless, some of the issues of the RHV export > described above for Debian guests should apply also in this case. thanks for your info:) I compare the virtio info between original ubuntu guest installed on vmware and converted ubuntu guest by v2v in /boot/config-$kernel file, there is no difference between them, pls refer to screenshot 'ubuntu-virtio' But I can't find virtio_scsi module in original ubuntu guest , this module will be produced in ubuntu guest after v2v conversion And I have another question about device.map of ubuntu guest, because original ubuntu guest has no device.map in /boot/grub. we can't check ubuntu's disk whether has been updated to vda via checking devcie.map after v2v conversion, could we just check the disk type by lsblk command? Is it enough?
Created attachment 1263221 [details] fstab_debian
Created attachment 1263222 [details] ubuntu-virtio
(In reply to mxie from comment #22) > (In reply to Pino Toscano from comment #21) > > (In reply to mxie from comment #11) > > > > For debian guest: > > > Scenario1: > > > 1.1 Prepare a debian guest and convert this guest to from kvm to rhv by > > > virt-v2v > > > # virt-v2v debian6 -o rhev -os 10.73.131.93:/home/nfs_export > > > [ 0.0] Opening the source -i libvirt debian6 > > > [ 0.0] Creating an overlay to protect the source from being modified > > > [ 0.3] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export > > > [ 0.4] Opening the overlay > > > [ 2.7] Inspecting the overlay > > > [ 3.6] Checking for sufficient free disk space in the guest > > > [ 3.6] Estimating space required on target for each disk > > > [ 3.6] Converting 6.0.4 to run on KVM > > > virt-v2v: warning: could not determine a way to update the configuration of > > > Grub2 > > > virt-v2v: warning: /files/etc/fstab/4/spec references unknown device "scd". > > > You may have to fix this entry manually after conversion. > > > > Can you please attach the /etc/fstab of the guest? > > Have attached the screenshot "fstab_debian" Thank you, it's useful indeed. /dev/scd0 looks like a SCSI CD device, which I never saw myself so far. I will patch virt-v2v to ignore this kind of devices, like we do for other kind of CD devices. > > > 1.2.1 Check virtio drivers in guest > > > # lsmod |grep virtio > > > virtio_console 2263 0 [permanent] > > > virtio_net 10493 0 > > > virtio_blk 4161 0 > > > virtio_pci 5495 0 > > > virtio_ring 3242 1 virtio_pci > > > virtio 3277 4 > > > virtio_console,virtio_net,virtio_blk,virtio_pci > > > > > > Result: > > > Debian guest doesn't have virtio_balloon module but have virtio_console > > > > virt-v2v does not do anything with balloon devices in the guest, so most > > probably this comes from other sources. Considering the scenario 2.2.1 > > shows virtio-balloon, I wonder whether there's something missing on RHV > > side. > > > > Wwas virtio_balloon loaded when running the guest before the v2v > > operation? > > I check the related virtio module in original debian guest which is > installed on qemu-kvm hypervisor, virtio_balloon and virtio_console both > exists in original debian guest before doing v2v conversion. > > But virito_balloon will be removed when convert debian guest from kvm to rhv > as scenario1 The cause here might be related to the fact that the guest description (kind of osinfo for RHV) is a "generic linux", and thus RHV might not use more specific information. I say "might" here as I'm not totally sure, yet. > And virtio_console will be removed when convert the guest from kvm to > openstack as scenario2 This might (again, as above) be due to the fact that the osinfo-db does not have detailed information for Debian guests. The newer osinfo-db coming in RHEL 7.4 might help with that (in this case, on OpenStack side). > If the debian is installed on vmware host, there is no related balloon > module in original debian guest, but the debian guest will include > virtio_balloon module after v2v converting from vmware to kvm as scenario3 Ditto. > > > For ubuntu guest: > > > > > > Scenario1 > > > 1.1 Prepare a Ubuntu guest and convert this guest to from kvm to rhv by > > > virt-v2v > > > [..] > > > 1.2.1 Check virtio driver in guest > > > # lsmod |grep virtio > > > virtio_scsi 20480 0 > > > > In the Ubuntu kernels, some virtio features are compiled built-in in the > > kernel, and not as module: you can check by grepping for VIRTIO in the > > /boot/config-$kernel files, noticing there are more features as 'y' > > (instead of 'm'). Nevertheless, some of the issues of the RHV export > > described above for Debian guests should apply also in this case. > > thanks for your info:) > > I compare the virtio info between original ubuntu guest installed on vmware > and converted ubuntu guest by v2v in /boot/config-$kernel file, there is no > difference between them, pls refer to screenshot 'ubuntu-virtio' The kernel is the same, so its configuration is the same too :) Sorry I was not clear: the difference is between the Debian kernel, and the Ubuntu kernel. > But I can't find virtio_scsi module in original ubuntu guest , this module > will be produced in ubuntu guest after v2v conversion Do you mean when running on ESX? > And I have another question about device.map of ubuntu guest, because > original ubuntu guest has no device.map in /boot/grub. we can't check > ubuntu's disk whether has been updated to vda via checking devcie.map after > v2v conversion, could we just check the disk type by lsblk command? Is it > enough? Yes, most probably so.
With libguestfs-1.36.2-2.el7 there should be few improvements: 1) when convering to RHV, v2v uses a more specific OS description for Debian 7+, and Ubuntu 12.04+: this means such versions (and greater) may be handled differently/better in RHV 2) /boot/grub/device.map is updated 3) the warning about the fstab entry "scd" is gone As result of (1), you could notice changes only when exporting to RHV Debian guests version 7 and up, and Ubuntu version 12.04 and up. This means your test with Debian 6 surely will have no changes. I will keep investigating on the other issues.
Verify the bug with below builds again: virt-v2v-1.36.2-2.el7.x86_64 libguestfs-1.36.2-2.el7.x86_64 libvirt-3.1.0-2.el7.x86_64 qemu-kvm-rhev-2.8.0-6.el7.x86_64 Debian guest:8.7.1-amd64 Ubuntu guest:16.10-amd64 Steps: For debian guest: Scenario1: 1.1 Prepare latest version debian8.7.1 guest and convert this guest to from kvm to rhv by virt-v2v # virt-v2v debian8.7.1 -o rhv -os 10.73.131.93:/home/nfs_export -b ovirtmgmt -n ovirtmgmt [ 0.0] Opening the source -i libvirt debian8.7.1 [ 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 [ 1.3] Inspecting the overlay [ 1.9] Checking for sufficient free disk space in the guest [ 1.9] Estimating space required on target for each disk [ 1.9] Converting 8.7 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 5.8] Mapping filesystem data to avoid copying unused and blank areas [ 5.8] Closing the overlay [ 6.0] Checking if the guest needs BIOS or UEFI to boot [ 6.0] Assigning disks to buses [ 6.0] Copying disk 1/1 to /tmp/v2v.TLUYEm/165c1942-70e7-4691-aa63-9184a0569bf2/images/9ac0aa56-ccc2-4e86-a631-c3c8deac1fea/5e88b902-2e91-4160-ae8b-0c2f5ab08086 (qcow2) (100.00/100%) [ 87.3] Creating output metadata [ 87.4] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 1.2.Check points for debian8.7.1 guest at rhv 1.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_console virtio_scsi virtio_net virtio_blk virtio_pci virtio_ring ... virtio ... Result:Compare with original debian guest, virtio_scsi and virtio_blk are new added after v2v conversion, I think this result is excepted 1.2.2 Check if disk has been update to vda, because there is no device.map in original debian8.7.1 guest, so check disk type by lsblk command #lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 1 10G 0 disk ├─vda1 253:1 0 9.6G 0 part / ├─vda2 253:2 0 1K 0 part └─vda5 252:1 0 466M 0 part [swap] Result:disk of debian guest has been update to vda 1.2.3 Check ip status in guest # ip a list ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:98:8a:53 brd ff:ff:ff:ff:ff:ff inet 10.66.146.100/24 brd 10.66.147.255 scope global dynamic eth0 ... Result: guest could get ip normally 1.2.4 Check qxl driver in guest, #cat /var/log/Xorg.0.log |grep qxl ... [177.887] qxl_surface_create:Bad bpp : 1 (1) ... #lspci -v |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc.QXL paravirtual graphic card (rev 04)(prog-if 00 [VGA controller]) Result：Guest has install qxl driver normmally Scenario2: 2.1 Convert debian8.7.1 guest to from kvm to openstack by virt-v2v # virt-v2v debian8.7.1 -o glance [ 0.0] Opening the source -i libvirt debian8.7.1 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o glance [ 3.5] Opening the overlay [ 5.2] Inspecting the overlay [ 6.3] Checking for sufficient free disk space in the guest [ 6.3] Estimating space required on target for each disk [ 6.3] Converting 8.7 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 17.6] Mapping filesystem data to avoid copying unused and blank areas [ 17.8] Closing the overlay [ 18.0] Checking if the guest needs BIOS or UEFI to boot [ 18.0] Assigning disks to buses [ 18.0] Copying disk 1/1 to /var/tmp/glance.WNVdiB/sda (qcow2) (100.00/100%) [ 95.4] Creating output metadata +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | architecture | x86_64 | | checksum | f53ebae42f7b6b1d51e613840189d7b6 | | container_format | bare | | created_at | 2017-03-16T08:09:06Z | | disk_format | qcow2 | | hw_disk_bus | virtio | | hw_video_model | qxl | | hw_vif_model | virtio | | hypervisor_type | kvm | | id | ab9f8223-6df6-427f-a529-c7fb92723ad5 | | min_disk | 0 | | min_ram | 1024 | | name | debian8.7.1 | | os_distro | debian | | os_type | linux | | os_version | 8.7 | | owner | 6c4dac53186d44fcbac29d3f3f575125 | | protected | False | | size | 4052221952 | | status | active | | tags | [] | | updated_at | 2017-03-16T08:09:52Z | | virtual_size | None | | visibility | private | | vm_mode | hvm | +------------------+--------------------------------------+ [ 149.1] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 2.2 Check points for debian8.7.1 guest at openstack, the result of checkpoints are same as step1.2 of scenario1 Scenario3: 3.1 Convert debian8.7.1 guest from vmware to kvm by virt-v2v, # virt-v2v -ic vpx://root.75.182/data/10.73.72.75/?no_verify=1 esx5.1-debian8.7.1-x86_64 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.75/?no_verify=1 esx5.1-debian8.7.1-x86_64 [ 1.1] Creating an overlay to protect the source from being modified [ 1.8] Initializing the target -o libvirt -os default [ 1.9] Opening the overlay [ 12.4] Inspecting the overlay [ 20.8] Checking for sufficient free disk space in the guest [ 20.8] Estimating space required on target for each disk [ 20.8] Converting 8.7 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 240.0] Mapping filesystem data to avoid copying unused and blank areas [ 242.7] Closing the overlay [ 243.8] Checking if the guest needs BIOS or UEFI to boot [ 243.8] Assigning disks to buses [ 243.8] Copying disk 1/1 to /var/lib/libvirt/images/esx5.1-debian8.7.1-x86_64-sda (raw) (100.00/100%) [ 575.6] Creating output metadata Pool default refreshed Domain esx5.1-debian8.7.1-x86_64 defined from /tmp/v2vlibvirtc486b4.xml [ 582.5] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 3.2 Check points for debian8.7.1 guest at kvm,the most result of checkpoints are same as step1.2 of scenario1 except step1.2.1 3.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_balloon virtio_scsi virtio_net virtio_blk virtio_pci virtio_ring ... virtio Result:Because there is virtio module in original debian guest which is installed on vmware host, all these virtio modules are new added after v2v conversion, I think this result is expected Scenario4: 4.1 Convert debian6 guest from vmware to kvm by virt-v2v, # virt-v2v -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-debian6-x86_64 --password-file /tmp/passwd -on debian6-new [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-debian6-x86_64 [ 2.0] Creating an overlay to protect the source from being modified [ 3.3] Initializing the target -o libvirt -os default [ 3.3] Opening the overlay [ 22.9] Inspecting the overlay [ 62.1] Checking for sufficient free disk space in the guest [ 62.1] Estimating space required on target for each disk [ 62.1] Converting 6.0.4 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 321.5] Mapping filesystem data to avoid copying unused and blank areas [ 346.2] Closing the overlay [ 346.6] Checking if the guest needs BIOS or UEFI to boot [ 346.6] Assigning disks to buses [ 346.6] Copying disk 1/1 to /var/lib/libvirt/images/debian6-new-sda (raw) (100.00/100%) [ 760.2] Creating output metadata Pool default refreshed Domain debian6-new defined from /tmp/v2vlibvirta690e6.xml [ 761.7] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 4.2 Check points for debian6 guest after v2v conversion 4.2.1 Check virtio drivers in guest # lsmod |grep virtio virtio_ballon 2961 0 virtio_net 10573 0 virtio_blk 4209 0 virtio_pci 5495 0 virtio_ring 3258 1 virtio_pci virtio 3309 4 virtio_ballon,virtio_net,virtio_blk,virtio_pci 4.2.2 Check device.map and disk type in guest #cat /boot/grub/device.map (hd0) /dev/vda #df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 16G 3.2G 12G 23% / ... Result:device.map is updated to vda 4.2.3 Check ip status in guest # ip a list ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:98:8a:53 brd ff:ff:ff:ff:ff:ff inet 192.168.122.227/24 brd 192.168.122.255 scope global dynamic eth0 ... Result: guest could get ip normally 4.2.4 Check qxl driver in guest, #lspci -v |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev 04)(prog-if 00 [VGA controller]) Result：Can‘t find qxl driver in debian6 guest For ubuntu guest: Scenario1 1.1 Prepare latest version Ubuntu16.10 guest and convert this guest to from kvm to rhv by virt-v2v # virt-v2v ubuntu16.10 -o rhv -os 10.73.131.93:/home/nfs_export -b ovirtmgmt -n ovirtmgmt [ 0.0] Opening the source -i libvirt ubuntu16.10 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 0.8] Opening the overlay [ 5.5] Inspecting the overlay [ 6.9] Checking for sufficient free disk space in the guest [ 6.9] Estimating space required on target for each disk [ 6.9] Converting Ubuntu 16.10 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 24.7] Mapping filesystem data to avoid copying unused and blank areas [ 27.5] Closing the overlay [ 28.9] Checking if the guest needs BIOS or UEFI to boot [ 28.9] Assigning disks to buses [ 28.9] Copying disk 1/1 to /tmp/v2v.13QP4Q/165c1942-70e7-4691-aa63-9184a0569bf2/images/932dab71-3ce3-4c06-abff-f4be8fee947f/6320c1af-bde5-47be-b465-b14ffac9cde4 (qcow2) (100.00/100%) [ 92.1] Creating output metadata [ 92.3] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 1.2 Check points for ubuntu guest at rhv as below 1.2.1 Check virtio driver in guest # lsmod |grep virtio virtio_scsi 20480 0 Result:virtio_scsi was new added after v2v conversion 1.2.2 Check if disk has been update to vda, because there is no device.map in original debian8.7.1 guest, so check disk type by lsblk command #lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 1 15G 0 disk ├─vda1 253:1 0 487M 0 part /boot ├─vda2 253:2 0 1K 0 part ├─vda5 253:5 0 14.5G 0 part ├─ubuntu-vg-root 252:0 0 13.5G 0 lvm / └─ubuntu-vg-swap_1 252:1 0 1G 0 lvm [swap] Result:the disk of ubuntu guest has been update to vda 1.2.3 Check ip status in guest # ip a list .... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:50:56:98:8a:53 brd ff:ff:ff:ff:ff:ff inet 10.66.146.17/22 brd 10.66.147.255 scope global dynamic eth0 .... Result: guest could get ip normally 1.2.4 Check qxl driver in guest #lspci -v |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc.QXL paravirtual graphic card (rev 04)(prog-if 00 [VGA controller]) Result:guest could be installed qxl driver normally Scenario2: 2.1 Convert ubuntu16.10 guest to openstack by virt-v2v # virt-v2v ubuntu16.10 -o glance [ 0.0] Opening the source -i libvirt ubuntu16.10 [ 0.0] Creating an overlay to protect the source from being modified [ 0.4] Initializing the target -o glance [ 1.2] Opening the overlay [ 4.8] Inspecting the overlay [ 6.0] Checking for sufficient free disk space in the guest [ 6.0] Estimating space required on target for each disk [ 6.0] Converting Ubuntu 16.10 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 24.5] Mapping filesystem data to avoid copying unused and blank areas [ 25.9] Closing the overlay [ 26.1] Checking if the guest needs BIOS or UEFI to boot [ 26.1] Assigning disks to buses [ 26.1] Copying disk 1/1 to /var/tmp/glance.747Dnt/sda (qcow2) (100.00/100%) [ 46.0] Creating output metadata +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | architecture | x86_64 | | checksum | 9b8c6128de046b7f525dd692910f9d72 | | container_format | bare | | created_at | 2017-03-16T08:17:51Z | | disk_format | qcow2 | | hw_disk_bus | virtio | | hw_video_model | qxl | | hw_vif_model | virtio | | hypervisor_type | kvm | | id | f9d63087-4ea1-4df0-9d98-a0b3e0f29ec9 | | min_disk | 0 | | min_ram | 1024 | | name | ubuntu16.10 | | os_distro | ubuntu | | os_type | linux | | os_version | 16.10 | | owner | 6c4dac53186d44fcbac29d3f3f575125 | | protected | False | | size | 1642921984 | | status | active | | tags | [] | | updated_at | 2017-03-16T08:18:09Z | | virtual_size | None | | visibility | private | | vm_mode | hvm | +------------------+--------------------------------------+ [ 65.8] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 2.2 Check points for unbuntu guest on openstack,the result of checkpoints are same as step1.2 of scenario1 Scenario3: 3.1 Convert ubuntu16.10 guest from vmware to kvm by virt-v2v # virt-v2v -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-ubuntu16.10-x86_64 --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-ubuntu16.10-x86_64 [ 4.0] Creating an overlay to protect the source from being modified [ 5.4] Initializing the target -o libvirt -os default [ 5.8] Opening the overlay [ 51.5] Inspecting the overlay [ 159.6] Checking for sufficient free disk space in the guest [ 159.6] Estimating space required on target for each disk [ 159.6] Converting Ubuntu 16.10 to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 959.0] Mapping filesystem data to avoid copying unused and blank areas [ 991.0] Closing the overlay [ 995.7] Checking if the guest needs BIOS or UEFI to boot [ 995.7] Assigning disks to buses [ 995.7] Copying disk 1/1 to /var/lib/libvirt/images/esx5.5-ubuntu16.10-x86_64-sda (raw) (100.00/100%) [1124.9] Creating output metadata Pool default refreshed Domain esx5.5-ubuntu16.10-x86_64 defined from /tmp/v2vlibvirtf6f828.xml [1137.9] Finishing off Result:only showing virt-v2v warning about Grub2 during v2v conversion which is expected result 3.2 Check points for unbuntu after finishing v2v conversion, the most result of checkpoints are same as step1.2 of scenario1 except step1.2.3 3.2.3 Check network status in guest # ip a list .... 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc state DOWN group default qlen 1000 link/ether 00:50:56:b7:d6:8a brd ff:ff:ff:ff:ff:ff .... #cat etc/network/interfaces .... auto ens32 iface ens32 inet dhcp .... Result: Because the NIC name of 'ip a list' is different with the name in network interface of script, guest can't get ip normally after virt-v2v converting from vmware to kvm Hi Pino, As you said, with libguestfs-1.36.2-2.el7, there be below improvements 1）the warning about the fstab entry "scd" is gone when converting debian guest by virt-v2v 2)Because debian8 has no device.map, I can't check disk type updating via device.map for debian8 guest, but the device.map of debian6 guest could be updated to vda normally with libguestfs-1.36.2-2.el7 But there are some problem with libguestfs-1.36.2-2.el7 1)For debian guest-> scenario4 -> step4.2.4: can't find qxl driver in debian6 guest but can find qxl driver in debian8 (scenario3) 2)For ubuntu guest ->Scenario3 -> step 3.2.3 : guest can't obtain ip after converting from vmware to kvm by v2v 3)I found v2v will installed virtio_scsi and virtio_blk modules for debian guest, why v2v just install virtio_scsi for ubuntu guest ? I have not got the meaning of below sentence,could you give me more info? 1) when convering to RHV, v2v uses a more specific OS description for Debian 7+, and Ubuntu 12.04+: this means such versions (and greater) may be handled differently/better in RHV
Hi Ming Xie, first of all, thanks for your testing. (In reply to mxie from comment #27) > 1)For debian guest-> scenario4 -> step4.2.4: can't find qxl driver in > debian6 guest but can find qxl driver in debian8 (scenario3) > > 2)For ubuntu guest ->Scenario3 -> step 3.2.3 : guest can't obtain ip after > converting from vmware to kvm by v2v IIRC these two issues were already in the previous version, right? > 3)I found v2v will installed virtio_scsi and virtio_blk modules for debian > guest, why v2v just install virtio_scsi for ubuntu guest ? This is what I mentioned before regarding the differences of the Ubuntu kernel: virtio_blk in Ubuntu is built in the kernel, so it will not show up as module. > I have not got the meaning of below sentence,could you give me more info? > > 1) when convering to RHV, v2v uses a more specific OS description for Debian > 7+, and Ubuntu 12.04+: this means such versions (and greater) may be handled > differently/better in RHV When we write the metadata for RHV, now there is a better description of the guest, for example "debian_8" or "ubuntu_14_04". RHV uses this particular description to provide better hardware in the guest itself, for example enabling certain types of disk types (virtio, for example), of audio card, or minimum/maximum available ram, and so on.
> > 1)For debian guest-> scenario4 -> step4.2.4: can't find qxl driver in > > debian6 guest but can find qxl driver in debian8 (scenario3) > > > > 2)For ubuntu guest ->Scenario3 -> step 3.2.3 : guest can't obtain ip after > > converting from vmware to kvm by v2v > > IIRC these two issues were already in the previous version, right? Yes, libguestfs-1.36.2-1.el7.x86_64 already has above issues So keep this bug at ON_QA status until these issues are fixed ?
(In reply to mxie from comment #29) > > > 1)For debian guest-> scenario4 -> step4.2.4: can't find qxl driver in > > > debian6 guest but can find qxl driver in debian8 (scenario3) > > > > > > 2)For ubuntu guest ->Scenario3 -> step 3.2.3 : guest can't obtain ip after > > > converting from vmware to kvm by v2v > > > > IIRC these two issues were already in the previous version, right? > > Yes, libguestfs-1.36.2-1.el7.x86_64 already has above issues > > So keep this bug at ON_QA status until these issues are fixed ? I'd say so -- I'll keep investigating them.
(In reply to mxie from comment #27) > 4.2.4 Check qxl driver in guest, > #lspci -v |grep VGA > 00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev > 04)(prog-if 00 [VGA controller]) > > Result：Can‘t find qxl driver in debian6 guest This is just different naming in lspci database. You can verify with: # lspci -nn |grep VGA You should see the PCI vendor/device IDs 1b36:0100.
(In reply to Tomáš Golembiovský from comment #33) > (In reply to mxie from comment #27) > > 4.2.4 Check qxl driver in guest, > > #lspci -v |grep VGA > > 00:02.0 VGA compatible controller: Red Hat, Inc. Device 0100 (rev > > 04)(prog-if 00 [VGA controller]) > > > > Result：Can‘t find qxl driver in debian6 guest > > This is just different naming in lspci database. You can verify with: > > # lspci -nn |grep VGA > > You should see the PCI vendor/device IDs 1b36:0100. Yes, the PCI vendor/device ID of debian6 guest VGA is 1b36:0100 after v2v conversion, so the qxl driver has been installed in debian6 guest after v2v conversion
Will verify the bug again when the problem "ubuntu guest can't obtain ip after converting from vmware to kvm by virt-v2v" is fixed
(In reply to mxie from comment #35) > Will verify the bug again when the problem "ubuntu guest can't obtain ip > after converting from vmware to kvm by virt-v2v" is fixed Is it the only combination that does not work? What about Ubuntu vmware->rhv or kvm->rhv?
Hi Pino， 1.Ubuntu guest can't obtain ip after converting from vmware to rhv by virt-v2v 2.Ubuntu guest can't obtain ip after converting from vmware-to kvm by virt-v2v 3.Ubuntu guest could obtain ip after converting from kvm to rhv/openstack by virt-v2v For item1 and item2, the main reason is that v2v will change primary network name of ubuntu guest from ens160 to ens3 during conversion, like bug 1318922
I have filed the bug 1451597 to track the problem"ubuntu guest can't obtain ip after converting from vmware to rhv/kvm by virt-v2v", so move this bug to VERIFIED status according to comment39 and comment40
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