Old hardware calls for a refresh. Otherwise, you’ll be dealing with slow computers, meaning you’ll reduce your productivity and your company’s ROI. Even worse, slow computers are an open door for security breaches.
When refreshing your server hardware, you should consider your budget, support plan, warranty period, and capacity planning. But it’s another story when you’re refreshing server hardware to use it as a virtualization host. So I’ll be showing you 3 extra things you need to keep in mind when planning for a virtualization host hardware refresh.
3 Best Practices to Refresh Your Virtualization Hardware
When refreshing your virtual hardware, you can put yourself ahead of the game in many ways. These transitions aren’t always easy, so you want to try your best to make it as smooth as possible for your systems. I’ve got 3 of my favorite tips for making your virtual hardware refresh as easy as can be:
1. Don’t Focus Your Hardware Planning Solely on Capacity
When it comes to purchasing a virtualization host, the natural tendency is to try to estimate your future capacity requirements. You can then select server hardware with the CPU, memory, storage, and network resources to meet the anticipated demand.
While this type of capacity planning is undeniably important, it’s also important to consider any additional hardware requirements. For example, when Windows 11 was released, Microsoft included a TPM 2.0 chip among the hardware requirements. So, it seems that any future Windows releases will also have a similar requirement.
Finding a current-generation server that doesn’t include a TPM 2.0 chip is hard. But it’s worth your time to list TPM 2.0 among your hardware specifications before making a server purchase.
You should also consider GPU hardware. It’s becoming increasingly common for workloads, particularly those that leverage machine learning, to require a physical GPU. You may already have VMs running in your data center mapped to a physical GPU.
When purchasing new server hardware, consider how many GPUs you’ll need to invest in. It’s also important to think about how you’ll migrate GPU-dependent VMs off the old hardware and onto the new hardware. That’s because VMs don’t generally support live migration.
2. Consider How the Transition Will Impact Clustered Workloads
Cluster capacity is another key consideration when refreshing virtualization host hardware. More specifically, you’ll have to consider whether or not your failover clusters have any room for growth.
Suppose, for a moment, you run Hyper-V on a group of clustered Windows servers. The maximum number of nodes in a failover cluster is 64. If your cluster consists of fewer than 64 nodes, you can simply join the new servers to the existing cluster, live migrate VMs to the new hardware, and then evict your old servers from the cluster.
On the other hand, if you have a 64-node cluster, you won’t be able to join any new nodes to the cluster until you remove one or more of the old nodes. Removing a cluster node will momentarily reduce the cluster’s capacity, at least until you add the new node to the cluster. So you’ll have to consider the impact of the upgrade process on the cluster’s ability to absorb any node failures that might coincidentally occur at the time of the migration.
3. Assess the Impact of the Refresh on Normal Operations
If you’re running Hyper-V, you’ll have to consider whether or not you can live migrate your VMs to the new hardware. When you migrate a Hyper-V VM to dissimilar hardware, you may have to enable processor compatibility mode for the VM before moving it.
That said, you may have to shut down the VM to enable processor compatibility mode. Another option is to simply power down the VM before attempting the migration. In either case, you’ll need to plan for possible downtime.
The Bottom Line
When refreshing your virtualization hardware, you must consider factors beyond capacity planning estimates. Otherwise, you’ll be dealing with a slow computer that causes your company many problems. That’s because the hardware you choose directly impacts how easy or difficult the migration process will be.
You also shouldn’t focus your hardware planning solely on capacity when refreshing your hardware. In addition, you should consider how the transition will impact clustered workloads. Lastly, you must also assess the impact the refresh will have on normal operations.
If you have more questions in mind, check out the FAQ and Resources sections below.
Does a hardware refresh always necessitate using CPU compatibility mode?
No, not every situation requires using CPU compatibility mode. If the new hosts are architecturally similar to the old hosts, you probably won’t have to enable CPU compatibility mode. Likewise, you won’t have to worry about CPU compatibility if you were to replace all of the hosts at once rather than trying to work new hosts into an existing cluster.
Should I run burn-in tests?
Burn-in tests fell out of fashion at some point, but I still find it important for any hardware that’ll host mission-critical workloads. The basic idea behind a burn-in test is that when you plug in and power up a new server, that server is unproven. You have no idea at that point if the server will be reliable or if it contains faulty components that made it past quality control. A burn-in test is designed to confirm the integrity of the server’s hardware.
How do you go about performing a burn-in test?
Performing a burn-in test doesn’t have a standard method. Everyone has their ideas about what such a test entails. That said, you can find guides online that can walk you through the process.
Why is it difficult to live migrate a VM using a physical GPU?
A VM using GPU passthrough is linked to a specific GPU device within the server hardware. So, the hardware dependency once made live migrations impossible for such VMs. Today, you can live migrate GPU-accelerated VMs. That said, doing so requires you to have just the right hardware.
What are the requirements for using processor compatibility mode?
According to Microsoft, you can only enable or disable processor compatibility mode while a VM is off. Processor compatibility mode will allow you to move a running VM to a host with a different CPU version. That said, you can’t move a running VM to a host equipped with a processor from a different manufacturer. For such moves, you must shut down the VM, and processor compatibility mode isn’t required.
TechGenix: Article on Hyper-V Tricks
TechGenix: Article on GPU Assignments
Read more on GPU assignments within Hyper-V hosts.
TechGenix: Article on Hyper-V Monitoring
Find out about Hyper-V resource health monitoring.
Microsoft: Article on Processor Compatibility Mode
Microsoft: Article on Hyper-V Live Migration
Read more on Hyper-V live migration.