When a migrated VM ends up with a kernel it shouldn’t have, the instinct is to assume something’s wrong with the new server itself, a bad image, an old template, something on the CloudStack side. In our case the actual cause sits somewhere less obvious: the file transfer step of the migration tool itself. Once you understand how the tool provisions the destination VM, the whole problem makes a lot more sense, and so does the fix.<\/p>\n
Our migration tool provisions the destination VM fresh, spinning up a new CloudStack instance on the latest available OS image. That new instance already comes with a current, stable kernel installed as part of the base image itself, nothing wrong with it at that point. The next step is moving the application over from the old Virtuozzo container to that new VM, and that’s done with rsync.<\/p>\n
The problem is that an rsync transfer scoped too broadly doesn’t know to leave kernel related paths alone. If the sync includes directories like \/boot or \/lib\/modules, it will happily copy whatever kernel files existed on the old Virtuozzo container straight over the new VM’s own, already correct, kernel files. The destination VM started out with a perfectly good modern kernel and ends up with an old, outdated one overwritten on top of it by the migration itself.<\/p>\n
This one doesn’t announce itself the way a driver failure would. The VM still boots. The application still starts. Whatever breaks tends to show up as something vague, odd module errors, a service that behaves inconsistently, something that doesn’t cleanly map back to “the kernel is wrong” unless you specifically go check it. It looks like a hundred other post-migration issues before you actually compare what kernel is running against what should have been installed by the base image in the first place.<\/p>\n
How can we fix the Kernel Compatibility issue during Migration<\/b><\/p>\n