Background
Our company have about 40 Xen domains installed on single server, installed and managed by suite of proprietary programs. Most of the virtual servers are managed by our customers, and we don't have access to guest system. About ten domains are Windows fully virtualized servers, and use paravirtualized NICs. All servers use static network configuration.
We decided to drop the propritary solution and move all the domains to another server with pure Debian and Xen. We want all guests migrated without intervention from our customers, and without changing customer data. We don't need a live migration.
To make matters more complicated, the current Dom0 is Centos 5.8 with quite an old version of Xen (3.4), and uses xend toolstack (xm) for management. The new server is Debian Jessie with Xen 4.4 and libxenlight (xl), the old xend is not supported here. I have libvirt installed on both servers, but because of the differences, not all configuration can be copied. The DomU's configuration is not stored on the old server in files - the management suite uses some other way to define and manage guests.
I have a script that pauses old domain, copies the virtual filesystem (it's a LVM2's logical volume) to new machine, converts configuration to libvirt XML format, defines a new domain and starts it. It works well for Linux guests, but when I boot my Windows guest, it does not have network configured.
Configuration of the old domain:
(The format is SXP, and was generated by xm list -l urflowgow78eq3
. The identifiers are all opaque hashes - this is one of the reasons why we want to move away from it)
(domain
(domid 124)
(on_crash restart)
(uuid 909320a0-2770-2461-8c21-ef07fe9caf55)
(bootloader_args )
(vcpus 1)
(name urflowgow78eq3)
(on_poweroff destroy)
(on_reboot restart)
(cpus (()))
(bootloader )
(maxmem 1128)
(memory 1128)
(shadow_memory 10)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1439655183.09)
(cpu_time 53747.3287688)
(online_vcpus 1)
(image
(hvm
(kernel )
(videoram 4)
(hpet 0)
(stdvga 0)
(loader /usr/lib/xen/boot/hvmloader)
(vncunused 1)
(xen_platform_pci 1)
(boot c)
(rtc_timeoffset -21610)
(vncpasswd XXXXXX)
(pci ())
(pae 1)
(vpt_align 1)
(hap 1)
(viridian 1)
(acpi 1)
(localtime 0)
(timer_mode 2)
(vnc 1)
(nographic 0)
(guest_os_type default)
(pci_msitranslate 1)
(apic 1)
(monitor 0)
(usbdevice tablet)
(device_model /usr/lib64/xen/bin/qemu-dm)
(pci_power_mgmt 0)
(usb 0)
(xauthority /root/.Xauthority)
(isa 0)
(notes (SUSPEND_CANCEL 1))
)
)
(status 2)
(state -b----)
(store_mfn 1044476)
(device
(vif
(bridge lk92o857at1h25)
(uuid 979030f6-b3b6-fe7c-31d2-4a6c8d98f8c7)
(script /etc/xen/scripts/vif-bridge)
(ip 1.2.3.4)
(rate '6250000,50000')
(mac 00:16:3e:c6:49:dc)
(vifname s7s8j3onwrxw38)
(type ioemu)
(backend 0)
)
)
(device
(vbd
(uuid dde5f71d-d3e5-8e7f-81f2-25b9d3330a20)
(bootable 1)
(dev hda:disk)
(uname phy:/dev/q1jn2lg6voj8fj/yqr9r37ugfhx75)
(mode w)
(backend 0)
(bootable 1)
(VDI )
)
)
(device
(vfb
(vncpasswd XXXXX)
(vncunused 1)
(vnc 1)
(uuid 14058e82-f5cf-b646-bee9-273db560bd3b)
(location 0.0.0.0:5911)
)
)
(device
(console
(protocol vt100)
(location 3)
(uuid 9a055df5-5bd5-804e-9493-394040ed4099)
)
)
)
Configuration of the new domain: (libvirt XML format. All relevant devices, LVs and so on were created. As far as I can tell, the net config is exactly the same.)
<domain type='xen'>
<name>Windows</name>
<uuid>02a81bea-1020-d2fe-7f31-5625a1a6fecd</uuid>
<memory unit='KiB'>1155072</memory>
<currentMemory unit='KiB'>1155072</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='x86_64' machine='xenfv'>hvm</type>
<loader type='rom'>/usr/lib/xen/boot/hvmloader</loader>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<disk type='block' device='disk'>
<driver name='phy'/>
<source dev='/dev/XXX_vg0/Windows_lv1'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='ide' index='0'/>
<interface type='bridge'>
<mac address='00:16:3e:c6:49:dc'/>
<source bridge='xenbr0'/>
<ip address='1.2.3.4'/>
<script path='/etc/xen/scripts/vif-bridge'/>
<target dev='s7s8j3onwrxw38'/>
<model type='netfront'/>
</interface>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
</video>
</devices>
</domain>
The problem
There is a NIC in the migrated Windows guest marked "Xen Net Device Driver #2", with default setting (autoconfigured address), instead of static address. In Device Manager, there are two NICs: one marked as "Not connected to the computer" and the other one working. Both have exactly the same driver.
The autoconfigured NIC does work (confirmed by capturing DHCP requests from the correct MAC in Dom0), but with wrong configuration. Because of this, after booting, the new guest does not have Internet connection.
I think the disconnected interface is the one that was used before migration, and is configured with the correct IP address and so on. (I can't confirm it, because I don't know how to view configuration of inactive interface.) The new, connected interface is created because Windows think it is a new NIC, similar to Citrix Xen VM's lose networking but in my case, it's not changed from emulated to paravirtualized.
My questions
- How does Windows decide there is a new network interface?
- What can I change in Xen's configuration to make Windows not create new NIC and reuse old network configuration?