Description of problem: virt-v2v should check the ip info when specify guest's ip Version-Release number of selected component (if applicable): virt-v2v-1.42.0-5.module+el8.3.0+7152+ab3787c3.x86_64 libguestfs-1.42.0-2.module+el8.3.0+6798+ad6e66be.x86_64 How reproducible: 100% Steps to Reproduce: 1.Check the --mac info from virt-v2v man page: --mac aa:bb:cc:dd:ee:ff:ip:ipaddr[,gw[,len[,ns,ns,...]]] Force a particular interface (controlled by its MAC address) to have a static IP address after boot. The fields in the parameter are: "ipaddr" is the IP address. "gw" is the optional gateway IP address. "len" is the subnet mask length (an integer). The final parameters are zero or more nameserver IP addresses. 2.Prepare a windows guest which dhcp client is disabled in VMWARE Scenario 1:ip info contains non-numberical character # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-no-dhcp -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem --mac 00:50:56:83:fe:60:ip:10.66.147.202,[@！#￥%……:*opij10.66.147.254,24 [ 0.8] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-no-dhcp -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 2.4] Creating an overlay to protect the source from being modified [ 5.7] Opening the overlay [ 13.9] Inspecting the overlay [ 19.0] Checking for sufficient free disk space in the guest [ 19.0] Estimating space required on target for each disk [ 19.0] Converting Windows Server 2019 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win/virtio-win.iso The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 33.4] Mapping filesystem data to avoid copying unused and blank areas [ 34.4] Closing the overlay [ 34.7] Assigning disks to buses [ 34.7] Checking if the guest needs BIOS or UEFI to boot [ 34.7] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data [ 37.9] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.W3lH5I/nbdkit4.sock", "file.export": "/" } (raw) (100.00/100%) [ 597.3] Creating output metadata [ 599.0] Finishing off Result 1:virt-v2v doesn't check the ip info Scenario 2: Give illegal ip info in command # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem --mac 00:50:56:83:62:d2:ip:1000.730.224.200[,1000.72.15.255[240]] [...] [ 35.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.nr9l5a/nbdkit4.sock", "file.export": "/" } (raw) (100.00/100%) [1213.0] Creating output metadata [1214.6] Finishing off Result 2: V2V doesn't check whether the ip value is legal Actual results: As above testing Expected results: virt-v2v should check the ip info when specify guest's ip Additional info:
Maybe the bug is duplicated with bug1685809
(In reply to mxie from comment #1) > Maybe the bug is duplicated with bug1685809 No,I think it's different problem. For scenario non-numerical character,virt-v2v can give error info when test below scenario,so I think virt-v2v should directly fail. # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win10-no-dhcp -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem --mac 00:50:56:83:e5:b2:ip:10.66.147.201[,10.66.147.254[,24]] virt-v2v: error: cannot parse --mac ip prefix length field as an integer: 24]] If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...]
(In reply to mxie from comment #1) > Maybe the bug is duplicated with bug1685809 It's different problem. Maybe I‘m not describe in comment0，so add more test scenarios: 1.# virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win10-no-dhcp -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem --mac 00:50:56:83:e5:b2:ip:10.66.147.201{,10.66.147.254,24} virt-v2v: error: expecting a libvirt guest name on the command line If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 1: virt-v2v give an error info ,but the error info is not expected. 2.# virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win10-no-dhcp -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem {} --mac 00:50:56:83:e5:b2:ip:10.66.147.201,10.66.147.254[,,%24] virt-v2v: error: cannot parse --mac ip prefix length field as an integer: If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 2: virt-v2v can give an error info 3.#virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-no-dhcp -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem --mac 00:50:56:83:fe:60:ip:10.66.147.202,[@！#￥%……:*opij10.66.147.254,24 [ 0.8] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-no-dhcp -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [...] [ 37.9] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.W3lH5I/nbdkit4.sock", "file.export": "/" } (raw) (100.00/100%) [ 597.3] Creating output metadata [ 599.0] Finishing off Result 3:virt-v2v doesn't check the ip info
Basically the only field we validate is the length (and even that we don't validate fully). So you can write this sort of thing: $ virt-v2v --mac 11:22:33:44:55:66:ip:hello,world,999,invalid -i disk test1.img -o null which is obvious nonsense.
I added a very simple test here: https://github.com/libguestfs/virt-v2v/commit/e8bcf9615490447e1b53a8b0d3e9d202ab178cf0 Seems low risk for RHEL AV 8.3.0.
Verify the bug with below builds: virt-v2v-1.42.0-6.module+el8.3.0+7898+13f907d5.x86_64 libguestfs-1.42.0-2.module+el8.3.0+6798+ad6e66be.x86_64 libvirt-6.6.0-4.module+el8.3.0+7883+3d717aa8.x86_64 qemu-kvm-5.1.0-4.module+el8.3.0+7846+ae9b566f.x86_64 nbdkit-1.22.0-1.module+el8.3.0+7898+13f907d5.x86_64 Steps: 1.Convert a guest from VMware by virt-v2v and set characters in IP address for --mac option # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:mxie virt-v2v: error: cannot parse --mac ip ipaddr: doesn’t look like “mxie” is an IP address If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] 2.Convert a guest from VMware by virt-v2v and set length of subnet mask > 32 in --mac option 2.1 # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:192.168.1.1,192.168.1.2,33,10.1.1.1 -o null [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-sles15-x86_64-efi -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 1.7] Creating an overlay to protect the source from being modified [ 2.6] Opening the overlay [ 9.2] Inspecting the overlay [ 31.0] Checking for sufficient free disk space in the guest [ 31.0] Estimating space required on target for each disk [ 31.0] Converting SUSE Linux Enterprise Server 15 to run on KVM virt-v2v: This guest has virtio drivers installed. [ 94.1] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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 [ 94.8] Closing the overlay [ 95.2] Assigning disks to buses [ 95.2] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 95.2] Initializing the target -o null [ 95.2] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw) ^C (35.06/100%) 2.2 Found v2v will report error only when length of subnet mask > 128 in --mac option # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:192.168.1.1,192.168.1.2,129,10.1.1.1 -o null virt-v2v: error: --mac ip prefix length field is out of range If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] 3.Convert a guest from VMware by virt-v2v and set invalid address in --mac option 3.1 # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:192.168.1.1.1.1.1.1 -o null [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-sles15-x86_64-efi -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 1.8] Creating an overlay to protect the source from being modified [ 2.7] Opening the overlay [ 9.3] Inspecting the overlay [ 31.9] Checking for sufficient free disk space in the guest [ 31.9] Estimating space required on target for each disk [ 31.9] Converting SUSE Linux Enterprise Server 15 to run on KVM virt-v2v: This guest has virtio drivers installed. [ 94.9] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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 [ 95.8] Closing the overlay [ 96.1] Assigning disks to buses [ 96.1] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 96.1] Initializing the target -o null [ 96.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw) ^Cnbdkit: vddk[3]: error: write reply: NBD_CMD_BLOCK_STATUS: Broken pipe 3.2 # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:1 -o null [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-sles15-x86_64-efi -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 1.9] Creating an overlay to protect the source from being modified [ 2.9] Opening the overlay [ 9.6] Inspecting the overlay [ 31.7] Checking for sufficient free disk space in the guest [ 31.7] Estimating space required on target for each disk [ 31.7] Converting SUSE Linux Enterprise Server 15 to run on KVM virt-v2v: This guest has virtio drivers installed. [ 94.7] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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 [ 95.6] Closing the overlay [ 95.9] Assigning disks to buses [ 95.9] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 95.9] Initializing the target -o null [ 95.9] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw) ^C (0.00/100%) 3.3 # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:111111111111,00000100000,0000000020,000000000030 -o null [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-sles15-x86_64-efi -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 1.8] Creating an overlay to protect the source from being modified [ 2.8] Opening the overlay [ 9.3] Inspecting the overlay [ 32.1] Checking for sufficient free disk space in the guest [ 32.1] Estimating space required on target for each disk [ 32.1] Converting SUSE Linux Enterprise Server 15 to run on KVM virt-v2v: This guest has virtio drivers installed. [ 94.9] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/sda1 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 [ 95.7] Closing the overlay [ 96.1] Assigning disks to buses [ 96.1] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [ 96.1] Initializing the target -o null [ 96.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw) ^C (5.01/100%) 4.Convert a guest from VMware by virt-v2v and set suffix for DNS in --mac option # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-sles15-x86_64-efi -ip /home/passwd --mac 00:50:56:ac:cd:56:ip:192.168.1.1,192.168.1.2,22,lab.eng -o null virt-v2v: error: cannot parse --mac ip nameserver: doesn’t look like “lab.eng” is an IP address If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Hi Richard, (1)Please check the result of step2, v2v won't report error when 32 < length of subnet mask < 129 in --mac option, but I remember the maximum length of subnet mask is 32, pls help to confirm (2)Please check the result of step3, seems v2v can't recognize invalid address for IP, gateway, subnet mask and DNS in mac option （3)Please check the result of step4, v2v will report error info when set characters for DNS in --mac option,which I think is not a expected result, pls help to confirm. Thanks
(In reply to mxie from comment #9) > (1)Please check the result of step2, v2v won't report error when 32 < > length of subnet mask < 129 in --mac option, but I remember the maximum > length of subnet mask is 32, pls help to confirm The patch I added does not try to work out if the IP address is IPv4 (32 bit) or IPv6 (128 bit), and therefore when we check the subnet mask we only check it is >= 0 && <= 128 bits. The reason for this is that parsing IP addresses is very complicated (https://en.wikipedia.org/wiki/IPv4#Address_representations) > (2)Please check the result of step3, seems v2v can't recognize invalid > address for IP, gateway, subnet mask and DNS in mac option In this example you used several invalid IP addresses: --mac 00:50:56:ac:cd:56:ip:192.168.1.1.1.1.1.1 --mac 00:50:56:ac:cd:56:ip:1 and you're correct that virt-v2v should reject these, in an ideal world. However this comes back to parsing IP addresses being very complicated. We only reject IP addresses which seem completely wrong, in that they contain non-hexadecimal digits. See also: https://github.com/libguestfs/virt-v2v/blob/bfb5fba651cc70a482738aad8477520b0609642b/v2v/cmdline.ml#L50 https://github.com/libguestfs/virt-v2v/blob/bfb5fba651cc70a482738aad8477520b0609642b/v2v/cmdline.ml#L142-L150 > （3)Please check the result of step4, v2v will report error info when set > characters for DNS in --mac option,which I think is not a expected result, > pls help to confirm. Yes, this is correct. The DNS addresses should be IP addresses, and we reject them if they contain non-hexadecimal digits like letters as in this example.
> >（3)Please check the result of step4, v2v will report error info when set > > characters for DNS in --mac option,which I think is not a expected result, > > pls help to confirm. > Yes, this is correct. The DNS addresses should be IP addresses, and we > reject them if they contain non-hexadecimal digits like letters as in > this example. Check --mac option in v2v man page, v2v has already pointed out that the final parameters should be zero or more nameserver IP addresses. So I have no more question for the bug, move the bug from ON_QA to VERIFIED according to comment9 ~ comment10
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 (virt:8.3 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-2020:5137