When a Windows VPS that was previously provisioned on our Xen infrastructure is migrated to KVM there are three changes that affect the server:
- A new driver is required for the virtual disk
- A new driver required for the virtual network interface
- Windows treats the replacement network interface as a completely new device. The new device must be configured with the settings that were previously applied to the Xen network interface.
During the migration process, Mammoth will automatically apply the configuration changes required for your Windows VPS to boot on the new KVM infrastructure. The Windows KVM migration occurs in two phases:
- The first phase occurs while your VPS is offline during the migration. Our automated tooling will make the minimum modifications necessary for your VPS to boot from the KVM virtual disk. During this phase, migration software is copied onto the disk.
- The second phase occurs automatically when your VPS is booted after migration. Our migration software will finish re-configuring the server to match its previous Xen configuration.
This document details the precise changes that will be made during the migration process. For most customers this information is not going to be required, but may prove useful in understanding what exactly happens during the migration process.
Disk driver
Windows maintains an area of the registry called the "critical device database" - the subset of drivers required to initially boot the server. During the first phase of the migration we copy the KVM drivers onto your VPS disk and add the KVM virtual disk driver to the critical device database.
This process is required for the VPS to boot; if not completed then the server will immediately blue-screen (or equivalent) when started as without the disk driver Windows cannot access any of its files.
During this phase the Xen driver is removed from the critical device database as Windows will not start if a critical device is missing.
Network driver
During the first phase of migration, the KVM network driver is copied into C:\Windows\Drivers but is not "installed". Along with this driver, we install our migration software to C:\Windows\KvmConv and add it to the registry as a Windows service to run at first boot.
At the start of the second phase of migration, Windows has the disk driver from the critical device database but is otherwise unconfigured - if you were to login from mPanel at the right moment, you would see that the network interface does not have an installed device driver.
When the VPS boots the KVM Migration Service that was installed during the first phase is started. This service adds RedHat (developer of the KVM device drivers) certificates to the Trusted Publishers section of the certificate database, and then installs the network interface driver.
Network configuration
After the KVM network interface driver is installed, the network interface will have no configuration and will default to DHCP (which is of no use, as Mammoth Cloud uses static IP assignment). Our migration software will query the registry to examine the (now removed) Xen network device and will copy the following values to the KVM device:
- The interface name (e.g. "Local Area Connection" or "Ethernet")
- All assigned IPv4 addresses and default gateway/s
- DNS servers
- WINS servers
- DNS Domain suffix
- Dynamic DNS Registration
- TCP/IP NetBIOS state
Notably, these are all values seen in the IPv4 configuration area and IPv6 configuration is not automatically restored.
In the common situation where the VPS either is not using IPv6, or is using the automatically assigned IPv6 address via SLAAC then no further configuration is necessary. However if you have assigned one or more static IPv6 addresses from your accounts floating IPv6 range you will need to reassign the address/es manually after migration.
Final steps
After the network configuration is re-applied, the migration service deletes itself from the VPS and then requests a reboot. After the reboot is completed network settings will have been restored and the server will resume normal service.
Comments