Hypervisor Migration: What Changes on the Hardware Side
Licensing changes have pushed many organisations to reconsider their hypervisor, and the hardware implications of that move are frequently underestimated. This covers what changes on the hardware side when you migrate, whatever you migrate to.
Why hardware matters in a hypervisor migration
Because different hypervisors want different things from the storage layer, and that is where migrations run into trouble.
The pattern: a platform built for one hypervisor uses hardware RAID with controller-managed volumes. The replacement platform wants raw drives so its own software-defined storage can manage redundancy. Those are opposite requirements from the same controller.
So the question is not just whether the server is supported, but whether the storage configuration suits the new platform. Our storage architecture guide covers the categories.
The controller question
The single most common hardware issue in a hypervisor migration.
Hardware RAID controllers present finished volumes and hide the physical drives. Some platforms are happy with that; others want to see every drive individually to do their own replication, checksumming and repair.
HBA or pass-through mode presents raw drives. Software-defined storage generally wants this.
Three practical points.
Some RAID controllers can be switched to HBA mode, and doing so is destructive to existing array configuration. Plan the data move first.
Some cannot be switched and need replacing with a plain HBA. Our HBA guide covers what an IT-mode controller does, and our controller guide covers identifying what you have.
Cache and battery backup become irrelevant in pass-through mode, so a controller you paid extra for may be doing nothing.
Memory: the requirement that usually grows
Different hypervisors have different overheads, and software-defined storage in particular consumes memory on every host to run its storage layer.
The practical effect: a host sized adequately for one platform can be short on memory for another. Check the replacement platform’s stated requirements per host, including its storage overhead, before assuming existing hosts are sufficient.
This is a good moment to buy memory, since adding it to an existing host is far cheaper than a new host. Our DDR4 supply guide covers why waiting on DDR4 platforms carries risk, and our host sizing guide covers working out the number.
Networking: check before you commit
Three things.
Adapter support. Hardware compatibility lists differ between platforms. An adapter fully supported on one may have limited or no driver support on another. Our compatibility lists guide covers checking against the version you are moving to, not the one you have.
Bandwidth for storage replication. Software-defined storage replicates writes across hosts, which puts sustained traffic on the network that hardware RAID kept inside the chassis. 1GbE is frequently not enough; 10GbE or better is the usual requirement. Our 10GbE adapter guide covers the hardware.
A separate network for storage traffic, or at minimum separation at the switch. Our segmentation guide covers this.
Boot devices
Platforms differ in what they expect to boot from and how much write activity they generate on the boot device. Some write logs continuously, which wears low-endurance flash faster than expected.
Check the replacement platform’s boot device guidance. Where it recommends a durable device rather than a small flash module, follow it — a worn boot device takes the host down. Our boot devices guide covers the options, and our endurance guide covers judging write life.
What this means for buying
Four things worth budgeting for in a hypervisor migration.
HBAs or controller mode changes, where the new platform wants raw drives.
Additional memory per host, for the new platform’s overhead.
Faster networking, if moving to software-defined storage on 1GbE.
Boot devices with adequate endurance.
None of these is a new server, which is the point. A migration is frequently a components exercise rather than a refresh, and that is much cheaper. Our upgrade or replace guide covers making that call.
Frequently asked questions
Can I use my existing servers with a different hypervisor?
Usually yes, but check three things: whether the storage controller suits the new platform, whether memory is sufficient for its overhead, and whether your network adapters are on its compatibility list. The servers themselves are rarely the problem.
Why does software-defined storage want raw drives?
So it can do its own replication, checksumming and repair at the drive level. A hardware RAID controller hides the physical drives behind finished volumes, which prevents that.
Can I switch my RAID controller to HBA mode?
Some can, and doing so is destructive to existing array configuration, so move the data first. Some cannot and need replacing with a plain HBA. Check your exact controller model.
Will I need more memory after migrating?
Frequently yes, particularly where the new platform runs software-defined storage, which consumes memory on every host. Check the stated per-host requirement including storage overhead before assuming existing hosts suffice.
Is 1GbE enough for a new hypervisor cluster?
Usually not with software-defined storage, which replicates writes across hosts and puts sustained traffic on the network. 10GbE or better is the normal requirement, ideally on a separate network or at least separated at the switch.
Do I need to replace my servers to change hypervisor?
Rarely. A migration is frequently a components exercise — HBAs, memory, networking, boot devices — rather than a refresh, and that is far cheaper than new hosts.
Tell us your host models, controllers and network adapters, and we will tell you what the migration actually needs on the hardware side.
