Still installing Win 2012 R2 as Hyper-V Hosts, am I crazy?

[CloudMSP]

Guys, I seem to have so much trouble with production checks points, even on brand new 2016 hosts and 2016 guest? (and especially on migrated 2012 VM's), that I've taken to using Windows Server 2012 R2 as my hosts even when I have all WS 2016 Guests. Why? Because I always get a perfect snapshot and successful backup every time. I wish Veeam had a check box to do things the old way on 2016.

Am I crazy? Have all the production snapshot issues been resolved? I've had these issue even when everything is brand new. Nothing crazy going on here. I'd really like to start using 2016 for the hosts but a successful backup means more to me. In a few places with 2016 hosts I've had to resort to disabling application aware processing.

Please help!

[csydas]

You're not crazy, there's just a lot going on with HV2016 still. I know that last week there were integration services updates that came out that fixed a LOT of issues with DCs on 2016, so make sure your servers are up to date in your lab

But it's still a messy place with VHDsets, sometimes AVHDXs just don't wanna merge, etc. I've seen contemporaries who have amazing HyperV set-ups running full 2016 and it's damn impressive. I'm a VMware guy personally, but I have a lot of respect for what the Hyper V guys can pull off.

I'd say if you can spin up a 2016 lab patch everything up and try it for awhile. Isolate it completely and just test backups and see what's working and what isn't for you.

As far as I recall, the big bugbear is VHDsets right now. DCs should finally be resolved. Exchange should be resolved with a full set of patches on your Exchange server. But, test it out, see how it's working for you.

[JaySt]

you're not crazy. makes sense.
20 pages in this forum discussing known issues with server 2016, that's crazy
https://forums.veeam.com/microsoft-hype ... 38927.html

[Mike Resseler]

Hi all,

Harvey, I can only agree with you. If you have troubles today, continue to work with 2012R2 and play with a lab. At this moment, we actually have quite some customers running Windows Server 2016 as Hyper-V hosts. And VHDSets is indeed not working as it should unfortunately. (Too bad because that would be killer technology to start virtualizing some physical clusters).

The thing with ws2016 is that it requires also a more different thinking for your hosts. As MSFT moves Hyper-V to a "cloud-capable" hyper-v (Because it actually runs in Azure) it also means that you need to see that host as such. There is an upgrade path from 2012R2 but most people I talked to said they have rethought their implementation and that leads to better success in this space.

Today, Hyper-V hosts with the latest update, in combination with ReFS for the VM storage (and maybe even for the backup storage depending on what HW you have) seems to be giving good results (besides VHD set). That is at least if you have some good hardware running. But as Harvey says. Investigate in the research to build a good setup and once you are happy with it, then start the process of moving. The benefits are there, but getting the implementation right is important!

Cheers
Mike

[nmdange]

If I was building a Hyper-V setup new, I would definitely go with one of the Windows Server Software Defined Datacenter certified offerings. One of the issues Microsoft has had is that the WHQL logo certification for drivers does only very basic testing. So in the earlier 2012 days if your server happened to have Broadcom or Emulex NICs, you might have thought Hyper-V was horribly unstable, but if you chose a different vendor, you had no issues. The SDDC certification requires much more extensive testing of an actual Hyper-V setup which (hopefully) leads to much more reliable drivers.

I will say in my environment, I have not had any real issues with Hyper-V 2016 as far as backups are concerned other than VHD Sets still being broken. If anything, things have been better, because with 2012 R2 I run into the occasional issue when VSS snapshotting CSVs, which is no longer needed in 2016.

[CloudMSP]

I think you guys are working in a much larger space than I am. We typically work with customers with 1 Hyper-V host (NTFS) on a decent Dell server and 2-4 Guests all on site at a customer location. I actually know nothing about VHDSets right now. All I know is that I have more than one location where at least 1 VM simply will not production checkpoint and I have to turn off application aware processing. We all know about DC issues, but I've seen this on non DC's, and I've seen it on fresh 2016 DC's too. It just seems not worth it, on 2012R2 the backups just work. On 2016 even when it works, it might break from time to time and need a reboot, or sometimes production checkpoints just flat out don't work. I'm about to do a new server right now. I guess I will try 2016 fully patched again and this time try ReFS too. I hope I don't regret this. I will be migrating a 2016 VM from it.

[csydas]

Honestly, I hope for the best. I think 2016 has some great stuff, but for me, it's not ready yet. Though we're mainly VMware in our place, I've got a smallish HyperV cluster on one site and 2016 just ended up eating up tons of our time until I had to just shelve the project. Microsoft's going to need to prove to me that 2016 is ready, maybe an R2 or something will help. I genuinely am excited when I see Hyper-V working well in colleague's sites.

If you're running a pretty slim set up though, I can't imagine you'll have too many problems on a smaller scale. Just remember to let everything get patched all the way up, and keep it there. That seems to be the trick for the moment.

[Mike Resseler]

Yes, patching is certainly very important here. And not only for security reasons this time

And let's hope that some of the issues we see are solved in the upcoming LTSC release which is just announced.

PS: For those who see issues with production checkpoints that not flat out, are the OS-es inside those VMs fully patched? We have seen that to be an issue also. Hyper-V host up-to-date but the guest OS far beyond.