Bug 1858785

Created attachment 1701745 [details]
Guest's ip info

Hi zili,

   I can't reproduce the bug on rhel8.3 av. I found the static IP of your command line(comment0) is inconsistent with the IP of original vmware guest, pls check "vmware-guest-ip-zili.png", besides,I found the original vmware guest is still obtain IP from DHCP, pls check "vmware-guest-dhcp-setting-zili.png", could you please describe more clearly how did you disable the DHCP in guest? Anyway, I think the bug is duplicated with bug1858775 because the static IP of command line(comment0) is invalid so that v2v will ignore the setting of --mac option, meanwhile, v2v doesn't change network configuration(disable dhcp client) of guest after conversion which is a expected result.

My test for the bug;

Packages:
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
libvirt-6.5.0-1.module+el8.3.0+7323+d54bb644.x86_64
qemu-kvm-5.0.0-2.module+el8.3.0+7379+0505d6ca.x86_64
nbdkit-1.20.5-1.module+el8.3.0+7350+3d35c316.x86_64


Steps:
1. Prepare a windows guest which has static IP, gateway, subnet mask and DNS, pls refer to screenshot"windows-static-ip-before-mxie"

static ip: 192.168.122.11
subnet mask:255.255.248.0
default gateway:192.168.1.1
DNS server: 196.168.11.1 


2 Check MAC address of the guest
# virsh -c vpx://root.73.141/data/10.73.75.219/?no_verify=1 dumpxml esx6.7-win2019-static-ip
Enter root's password for 10.73.73.141: 
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
  <name>esx6.7-win2019-static-ip</name>
....
 <interface type='bridge'>
      <mac address='00:50:56:ac:90:79'/>
      <source bridge='VM Network'/>
      <model type='e1000e'/>
    </interface>
....

3 Convert the guest from VMware to rhv, set static IP address,gateway, subnet mask and DNS in --mac option， which are consistent with the setting in guest

# 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  -o rhv-upload -oo rhv-cafile=/home/ca.pem -oo rhv-direct -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd --password-file /home/passwd esx6.7-win2019-static-ip -of raw -os nfs_data --mac 00:50:56:ac:90:79:ip:192.168.122.11,192.168.1.1,21,196.168.11.1 -b ovirtmgmt 
[   1.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win2019-static-ip -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
[   2.7] Creating an overlay to protect the source from being modified
[   3.7] Opening the overlay
[  10.2] Inspecting the overlay
[  16.5] Checking for sufficient free disk space in the guest
[  16.5] Estimating space required on target for each disk
[  16.5] 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.
[  36.5] Mapping filesystem data to avoid copying unused and blank areas
[  37.6] Closing the overlay
[  37.9] Assigning disks to buses
[  37.9] Checking if the guest needs BIOS or UEFI to boot
[  37.9] 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
[  39.3] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.D5b34d/nbdkit4.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1023.9] Creating output metadata
[1025.8] Finishing off


4. Check the guest network after finishing conversion on rhv, power on and wait about 10min, found guest can get correct static IP, subnet mask, gateway and DNS IP, pls refer to screenshot"windows-static-ip-after-mxie"

Created attachment 1701835 [details]
vmware-guest-ip-zili.png

Created attachment 1701836 [details]
vmware-guest-dhcp-setting-zili.png

Created attachment 1701837 [details]
windows-static-ip-before-mxie.png

Created attachment 1701838 [details]
windows-static-ip-after-mxie.png

Hi,mxie
I disabled the dhcp client in guest,pls see screenshot named:Disabled dhcp client-zili

And I test the bug as the method you mentioned in comment2,I get below result:

Steps:
1. Prepare a guest in VMware, Make sure the DHCP Client server is running and set static IP, gateway, subnet mask and DNS to the guest 

Scenario 1:
Convert the guest from VMware to rhv, set static IP address,gateway, subnet mask and DNS in --mac option， which are consistent with the setting in guest
# 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  -o rhv-upload -oo rhv-cafile=/home/ca.pem -oo rhv-direct -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd --password-file /home/passwd esx6.7-win2019-static-ip -of raw -os nfs_data --mac 00:50:56:ac:90:79:ip:192.168.122.11,192.168.1.1,21,196.168.11.1 

Result 1: The guest can get correct static IP, subnet mask, gateway and DNS IP,and no error info in firstboot log.


Scenario 2:
Convert the guest from VMware to rhv, set static IP address,gateway, subnet mask and DNS in --mac option， which are not consistent with the setting in guest
#  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  -o rhv-upload -oo rhv-cafile=/home/ca.pem -oo rhv-direct -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd --password-file /home/passwd esx6.7-win2019-static-ip -of raw -os nfs_data --mac 00:50:56:ac:90:79:ip:10.66.147.202,10.66.147.254,24

Result 2:The guest cannot get correct static IP.


Hi,Rjones:
As above testing ,I have some problems want to confirm with you:
1.Should the guests must have running DHCP server?
2. If the static IP is inconsistent with internal IP setting of guest，the static IP set in --mac option will be ignored, is it expected?

Created attachment 1701881 [details]
DIsabled DHCP client server-zili

The aim of the --mac :ip: setting is that it should be able to set the static IP
of the address to something different from what it is already.  I do not think
that the guest needs a DHCP client running (not sure what it would be used for, since
we are giving it a static IP address).

However since I don't know much about Windows I'm going to ask if there's a
Windows expert who can help us with this.

I can't reproduce the Scenario 2 problem of comment7 now

Packages:
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
libvirt-6.6.0-2.module+el8.3.0+7567+dc41c0a9.x86_64
qemu-kvm-5.1.0-4.module+el8.3.0+7846+ae9b566f.x86_64
nbdkit-1.20.6-2.module+el8.3.0+7637+9ed826e0.x86_64


Steps:
Scenario1:

1.1 Prepare a guest which has static IP address, gateway, subnet mask and DNS on VMware, pls refer to 'scenario1-guest-before-conversion'
IP address: 192.168.122.11
gateway: 192.168.1.1
subnet mask: 255.255.248.0
DNS:196.168.11.1

1.2 Convert the guest from VMware to rhv by v2v, but set static IP address, gateway, subnet mask and DNS in --mac option which are not consistent with the setting in guest

#virt-v2v -i vmx -it ssh ssh://root.75.219/vmfs/volumes/esx6.7-function/esx6.7-win2019-static-ip/esx6.7-win2019-static-ip.vmx -o rhv-upload -oo rhv-cafile=/root/ca.pem -oo rhv-direct -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -of raw -oo rhv-cluster=Default -os nfs_data -b ovirtmgmt  --mac 00:50:56:ac:90:79:ip:10.73.75.102,10.73.75.254,22,10.73.224.1


1.3 Check guest on rhv after conversion, find guest get same static IP address, gateway, subnet mask and DNS with the setting of --mac option, pls refer to 'scenario1-guest-after-conversion'


Scenario2:

2.1 Prepare a guest which get ip from DHCP on VMware,pls refer to 'scenario2-guest-before-conversion'

2.2 Convert the guest from VMware to rhv by v2v, but set static IP address, gateway, subnet mask and DNS in --mac option 

# virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -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   -ip /home/passwd esx7.0-win2019-x86_64  -o rhv-upload -oo rhv-cafile=/root/ca.pem -oo rhv-direct -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -of raw -oo rhv-cluster=Default -os nfs_data -b ovirtmgmt  --mac 00:50:56:83:62:d2:ip:10.73.75.102,10.73.75.254,22,10.73.224.1

2.3  Check guest on rhv after conversion, find guest get same static IP address, gateway, subnet mask and DNS with the setting of --mac option if check the IP related info in Ethernet properties, but IP related info is incorrect if check with command 'ipconfig' pls refer to 'scenario2-guest-after-conversion'. I think the problem "ip related info of Ethernet properties is inconsistent with the output of ipconfig" has no relationship with virt-v2v

Created attachment 1713308 [details]
screenshots-for-comment13

Despite the fact that the bug has apparently gone away, I doubt that
we've fixed this properly so far.  After talking this over with some
Windows experts the best I can offer is that we modify the Powershell
code so it retries the New-NetIPAddress commands a few times, in the
hope that whatever RPC service the command is waiting comes up during boot.

Note it's almost impossible to properly debug this (ie. attach a Windows
debugger at boot) because of the environment where this runs.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

The previous comment is wrong, this bug is still on the backlog.

This is just another instance that network configuration is impossible to do reliably on Windows during firstboot. Remember that we moved "v2vnetcf.ps1" to the front of the firstboot scripts under bug 1788823, then it caused problems (bug 2068361). I'd demonstrated in <https://bugzilla.redhat.com/show_bug.cgi?id=2068361#c19> that the behavior was timing-related. I'm marking this similarly as "Devel Cond-NAK: Design". (Also reiterating Rich's comment 15 from first-hand experience: it's basically impossible to debug these issues; no matter how hard I tried in bug 2068361, I couldn't log *any* information in the failing cases, be it to the standard output or error, regular text files, the Windows event log, the system console etc.) The most viable avenue still appears to be to revert the patches for bug 1788823, and (maybe) to schedule "v2vnetcf.ps1" as late as possible. Not comfortable for the interactive user, yes, but at least has a chance of working.