Frequently Asked Questions
Why your migrated VM looks a little different on the target cloud, and what to expect.Getting Started
Which workflow should I use?
Milkshake offers two paths. The rescue-based workflow boots your existing instance into a temporary rescue session and is best when you want to migrate a VM in place with minimal preparation. The import / conversion workflow takes an image you already have in the target project, runs it through conversion, and produces a bootable target image. If you are migrating a running instance, start with the rescue workflow; if you already have an exported disk image to bring in, use import.
What credential do I need?
Milkshake needs a target-cloud application credential scoped to your project. The conversion work runs inside your tenant, so Milkshake authenticates as your project to read images, create one temporary conversion worker, upload the converted result, and manage its dedicated worker network. Use a dedicated, narrowly scoped credential rather than a broad admin credential. See the Application Credential Setup guide for the exact steps and an example access-rule file.
What is config_drive and why is it enabled on my instance?
Migrated instances boot with config_drive: true. This attaches the instance's cloud-init metadata as a small virtual drive instead of relying solely on the network metadata service. It makes first boot more reliable: cloud-init can read its configuration even if the metadata service is briefly unreachable. It is expected and safe to leave enabled.
What Changed Inside My VM
Migration moves your guest from one hypervisor to KVM/QEMU. A few things are deliberately changed so the guest boots and networks correctly on the target cloud. None of this indicates a problem.
Why is my kernel or initramfs different?
Your kernel version is normally the same, but the initramfs is rebuilt. The conversion step adds the virtio drivers (virtio_blk, virtio_scsi, virtio_net) the guest needs to see its disk and network on KVM. Without this the VM would not find its root device. If your guest had no installed kernel matching the new hardware, conversion may also select a compatible kernel; the original is left in place.
Why did my IP addresses change?
The source cloud's static network configuration is intentionally neutralized during conversion, and the primary interface is set to DHCP. On first boot, cloud-init and the target cloud assign addresses from the target network you placed the instance on. This avoids the guest coming up with addresses that are not valid on the new cloud. If you need fixed addressing, configure it on the target cloud (for example via a Neutron port) or inside the guest after first boot.
Do I need to update DNS for domains pointing at the old IP?
Yes. If a domain's A record (or AAAA record) points at the old cloud server IP, update it to the new address once the migrated instance is up. To make that cutover quick, lower the DNS TTL well in advance of the migration - for example to 300 seconds a day or two before - so resolvers pick up the new address promptly instead of caching the old one for hours. Raise the TTL again after the migration has settled.
If you must keep your existing public IP, contact your cloud provider before migrating. Public IPs can be carried over in certain circumstances, but doing so may incur an additional charge and is not automatic.
What happened to IPv6?
IPv6 is handed off to the target cloud and cloud-init rather than carried over from the source. Static IPv6 configuration from the source guest is not preserved. On Enterprise Linux guests, conversion sets IPV6INIT=no on the rewritten interface so a stale IPv6 setup cannot interfere with bringing the interface up over DHCP. If your target network advertises IPv6, the guest will pick it up normally on first boot; if you relied on static IPv6, reconfigure it after migration.
Note: Flex clouds do not support IPv6 at this time. If your workload depends on IPv6, plan for an IPv4-only target environment.
Why did my interface names or MAC addresses change?
Persistent network naming rules (the udev persistent-net rules) and the stored source MAC addresses are removed during conversion. Those rules pinned interface names to old hardware; keeping them would cause the guest to come up with no usable NIC. After removal, the guest uses whatever NIC the target cloud attaches, and interface naming follows the target's hardware.
Why does SSH warn about a changed host key?
This is expected. Your SSH client remembers the host key tied to the old address. After migration the same guest is reachable on new infrastructure, so the client sees what looks like a key mismatch. It is the same machine. Remove the stale entry to clear the warning:
Then reconnect and accept the host key once. The guest's own host keys are not regenerated by migration.
Why was my hostname reset?
The stored hostname is cleared during conversion so cloud-init can set it cleanly on the target cloud. On first boot cloud-init reassigns the hostname from the instance metadata. If you set a custom hostname, confirm it on the target instance after first boot.
What is qemu-guest-agent and why is it installed?
Conversion installs and enables qemu-guest-agent. The target cloud uses it for graceful shutdown, filesystem-consistent snapshots, and reporting the guest's IP addresses back to the cloud. At the same time, the legacy nova-agent is disabled because it is not used on the target cloud and can interfere. The old package is left installed but inactive.
Why does the bootloader look different?
The bootloader's root= entry is rewritten from a hypervisor-specific device path to a stable UUID= reference. The old path described the disk as the source hypervisor presented it; under virtio the device name differs, so a UUID is used to find the root filesystem reliably regardless of device naming.
Windows Guests
Why are there new virtio drivers?
Windows needs paravirtualized drivers to run on KVM. Conversion stages the viostor (storage) and netkvm (network) drivers so Windows can see its boot disk and network adapter on the target cloud. Windows binds them automatically on first boot.
Why were some drivers disabled?
Conversion disables source-hypervisor paravirtual drivers (Xen or VMware) and hypervisor-specific CPU power-management drivers such as intelppm and amdppm. Left enabled on KVM these can cause boot conflicts or a bootloop/BSOD. Disabling them is required for a clean boot on the target cloud.
My Windows network is set to DHCP - why?
As with Linux guests, the source NIC configuration is reset and Windows interfaces are set to obtain addresses via DHCP. This ensures the guest comes up with valid addressing on the target network. If the workload requires static addressing, reconfigure it inside Windows after first boot, or use a fixed-address Neutron port on the target cloud.
Troubleshooting & Limits
What if a conversion or build fails?
A failed conversion is usually retryable. Check the task detail in the migration workspace for the failure stage and log context, then retry the task. Transient cloud or network errors often clear on a second attempt. If a conversion fails repeatedly at the same stage, capture the task identifier and the reported error and raise it with your operator - the server keeps the detailed error even though the UI shows a short summary.
Are encrypted volumes supported?
Guest-level encrypted volumes (for example LUKS/dm-crypt inside the guest) are a known limitation: Milkshake does not unlock or convert encrypted volume contents, since it has no access to the encryption keys. Migrate such volumes by other means, or decrypt them before conversion. Cloud-side volume encryption handled transparently by the target cloud is not affected.
How do I reach the console if the VM will not boot?
Use the target cloud's noVNC console to watch the guest boot and interact with it directly. Converted guests also have a serial console enabled, which is useful for capturing boot logs when the graphical console is not enough. If the VM does not reach a login prompt, the console output usually shows whether it stalled in the bootloader, the initramfs, or networking.
What should I expect on the first boot?
First boot does more work than later boots. Cloud-init re-runs to apply the target cloud's metadata, the network comes up over DHCP, the guest agent finishes installing, and Windows guests bind their new virtio drivers. It is normal for the first boot to take a little longer and for the instance to settle its address shortly after powering on.