[TIP] A couple of HyperV tips I learned

[sctechsystems]

Hi all,

Although we are a Linux shop we do run a couple of HyperV solutions for businesses that we manage.

Here's a couple of tips that I have learnt:

• Replication, have a local replication server - replicate your Virtual Machines to this, you can also setup and configure replication offsite using certificates.
• Dynamic Memory: I was aware of this but never used it but it has made a world of difference: I used to set a Debian VM to use 2GB of RAM, I now use Dynamic Memory and can see a server using as little as 640 MB of RAM because that's all it needs, VM can use more if it needs to up to the threshold that is set.
• Management: We typically don't manage the hosts directly, we have a PC/Server with HyperV manager installed, add the hosts to the manager and manage them that way - Machine is secured with a very strong password and Two Factor.
• Don't Over allocate CPU cores, this can be a tricky one it's mainly trial and error.

If anyone has any more to add...please do!

 

[HCHTech]

I'm just starting to do this. From what I read about Dynamic Memory, it causes a performance hit, so I didn't choose that option, but it may well be that it is a small performance hit and it has a big benefit. Probably more important the more VMs you have on a host.

Do you install Hyper-V core on the host or use the GUI?

For your replication server - how is that physical machine setup? Does it have to be an existing server OS, or can you just run the (free) Hyper-V for the host OS, then setup the replication machine as a guest?

For my test machine, I have only a single guest, and I allocated all but two cores to the VM, leaving 2 for the host. Similarly, I allocated all but 8GB of RAM to the VM, leaving 8 for the host. From my initial monitoring, the host isn't really working that hard.

v3 guests require VHDx format for the virtual disks, v2 guests can still use VHD. From what I've read, the only reason to use VHD is if you have some other software that requires it...

v3 guests cannot attach a physical DVD drive, you must mount an ISO. v2 guests can still use a physical drive.

 

[sctechsystems]

I have Full GUI Server 2016 at the moment, I haven't seen a performance hit with using Dynamic Memory at all.

My replication server is just another server joined to the domain with the other HyperV server, HyperV role installed, on the main server just right-click a VM and go to enable replication. Select your replication server via its Sunday name, Select interval etc and it will sit all day receiving replications.

I don't think I've looked at v3 guests yet, think mine are mainly v2.

 

[HCHTech]

Select your replication server via its Sunday name

Haha, that made me chuckle. My first inclination was to reply "Ooh, look at Mr. Rockefeller with his special names for Sundays!", but then I thought it might be a spellcheck thing, but nothing came to mind. Is this a colloquialism for machine name, i.e. "Proper name"?

 

[TurricanII]

Format your data drives (that hold the VHD's) with 64k cluster size rather than default NTFS 4k

Do not use VM snapshots on live systems or, if you must take the odd snapshot, delete it as soon as possible afterwards to avoid terrible performance and disk space hit.

Assign as FEW vCPU's as possible to your VM - ideally two. If you assign e.g. four vCPU's to a VM then for some operations it must wait for all four cores to be available before it can proceed, causing a performance hit

You can do replication with the free hyper-V server. for small businesses I prefer to leave the HyperV servers off any domain, add a self signed cert to each, edit the HOSTS file if needed for the Hyper-V servers to resolve each other and replicate through HTTPS.

When replicating over slow DSL, make every effort to move disk traffic OFF the C: and data VHD's. This will reduce the amount of bandwith needed to send replica's off-site. Create a dedicated page file VHD and exclude that from replication. Watch the VM for any intensive disk activity and reduce that or move it to a VHD that is not replicated if you can.

 

[sctechsystems]

Format your data drives (that hold the VHD's) with 64k cluster size rather than default NTFS 4k

Do not use VM snapshots on live systems or, if you must take the odd snapshot, delete it as soon as possible afterwards to avoid terrible performance and disk space hit.

Assign as FEW vCPU's as possible to your VM - ideally two. If you assign e.g. four vCPU's to a VM then for some operations it must wait for all four cores to be available before it can proceed, causing a performance hit

You can do replication with the free hyper-V server. for small businesses I prefer to leave the HyperV servers off any domain, add a self signed cert to each, edit the HOSTS file if needed for the Hyper-V servers to resolve each other and replicate through HTTPS.

When replicating over slow DSL, make every effort to move disk traffic OFF the C: and data VHD's. This will reduce the amount of bandwith needed to send replica's off-site. Create a dedicated page file VHD and exclude that from replication. Watch the VM for any intensive disk activity and reduce that or move it to a VHD that is not replicated if you can.

+1 thanks - We have used the Certificate-based replication also. Typically, most of our VM's especially the Linux ones have 1-2 vCPU's assigned.
We never use SNapshots unless absolutely necessary, if we do it will be on a test server anyway, which usually don't live very long.

 

[sctechsystems]

Haha, that made me chuckle. My first inclination was to reply "Ooh, look at Mr. Rockefeller with his special names for Sundays!", but then I thought it might be a spellcheck thing, but nothing came to mind. Is this a colloquialism for machine name, i.e. "Proper name"?

Sunday Name: as in: hypervserver1.domain.local

 

[HCHTech]

Format your data drives (that hold the VHD's) with 64k cluster size rather than default NTFS 4k

Why is 64k better? This would also argue for NOT storing the VHDs on the same volume as the Host OS, which would have to be 4k, I suspect.

 

[TurricanII]

Why is 64k better? This would also argue for NOT storing the VHDs on the same volume as the Host OS, which would have to be 4k, I suspect.

To clarify, 64k clusters were recommended for an SQL Server deployment within a VM. Regular file servers may be better on 4K clusters. I guess the best advice is to consider your needs and find the appropriate Microsoft advice that happens to be in force that day of the week!