Hacker News Reader

Comment by teilo | Hacker News Reader

This doesn't surprise me overmuch. The foot in the door is Office 365 Enterprise, which comes with AD in Azure for free. From there, it's natural to setup a VPN to your Azure environment. With that in place, competitive pricing, and better compliance tools (such as host-external session-based flow monitoring) it becomes an attractive solution.

Tie that to experience with Hyper-V. Companies like mine who have unused Hyper-V capacity due to Microsoft's ridiculous VM licensing scheme for Windows, tend to run Linux instances on that extra capacity. The high performance of Linux on Hyper-V was an eye-opener for us. I could see us using Azure for Linux.

That said, we are 99% AWS, and I don't see our online platform ever moving from them.

View on HN

> Microsoft's ridiculous VM licensing scheme for Windows

Microsoft offers at least three different ways to license Windows to run on a VM in-house. Core count, instance count, or site. Are all three "ridiculous?"

None of Microsoft's license types require a certain Hyper-V capacity. In fact the whole "we were required to over-allocate Hyper-V so run Linux on the spare capacity" claim makes no sense.

Yes, they're all ridiculous. Also their licensing model is so hideously complex even different license advisors from Microsoft will give you different answers as to what you need. The only way you feel comfortable being fully in compliance with licensing is by massively overbuying. Its a ridiculous burden to place on a business.

There is no such thing as instance or site pricing for Windows Server. Where are you getting that from?

There is only core licensing, and you have to license all cores in a hypervisor, 16 minimum, and then you can only run two Windows Server instances unless you re-licensing all cores on the host a second time. The exception to that rule is Datacenter edition, which is only cost effective for large businesses running high-density servers. (7.5x the price for the same number of cores vs. Standard.)

http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4...

Yeah, I came here to mention Linux on Hyper-V - the performance is great, the free version, while painful to setup, its extremely low friction to keep running.

I had nothing but pain with Hyper-V hosting Linux, to the point we joked it came with Chaos Monkey built in.

Volumes would become read-only for no good reason, VMs would reboot...

At least, when we moved to AWS, our software was exquisitely resilient, with multiple levels of degraded functionality everywhere.

I've never really had any issues with it, and I'm doing stuff I consider to be a little esoteric, like volume passthru.

That's not so much esoteric as old-school. When VHD was the only other option, it was the standard way of getting decent performance out of iSCSI or large direct-attached volums. But with VHDX, passthrough gains you so little that it's not worth losing the ability to checkpoint volumes and do agentless backups.

My use case had to do with migrating a physical machine to a virtualized one, in this case migrating the whole array over (with its controller) was less risk fraught (and notably faster) than creating a new drive, and copying. It also creates an isolation layer between windows and my files.

Sometime in the next couple years I'll likely migrate it to a vhdx, but this was quick and easy to setup.

Physical to VHDX migration is a PITA. I've done it in an emergency, but it's not ideal. You can convert a raw drive image to VHD using the now-obsolete VHDTool, and from there convert to VHDX. But the resulting volume is not dynamic. It appears to have no way to know which sectors are in use when the conversion is done this way, so it assumes all of them are, and the image cannot be shrunk. The better option is to copy all contents to a new VHDX image using a utility instance. A lot more work, of course.

Too much abstraction there - in this case, I wouldn't convert, I'd copy, create a new VHDX mount it somewhere in the VM, copy the data over, then remount it in the VM at the mountpoint of the now unmounted RAID Array.

We ended up here, because as I mentioned, I just moved the RAID into the new box, and mounted at the place the VM needed to have it, that made the setup process much faster.

We currently have eight Linux instances up on Hyper-V, and have never seen any of these problems. The only thing we have to do is install the hyper-v tools for the corresponding Distro, and change the disk scheduler to noop. The kernel modules are ready out-of-the-box on Centos 7 and Ubuntu 16 LTS. Dynamic memory, snapshots, etc., all just work.

Hyper-V Server 2016 has improved things even further when running your images on ReFS. Near-instant checkpoint creation and merging.

It has worked so well that we abandoned ESX (except for one appliance maintained by an unenlightened vendor who refuses to support anything else), and KVM, and now manage all (but two) of our VMs in Hyper-V Manager. Plus, it makes backups a breeze, because (like most modern backup solutions) Arcserve UDP supports agentless backups of Hyper-V VMs.

What did you find painful about setting up Hyper-V Server?

I was using Hyper-V Core, and in an environment without a domain controller, so there is a bunch of manual setup so you can get a remote admin console working.

Yeah that can be a PITA. Samba is always an option if you want to make it a bit easier for yourself. You can run a domain for Windows (and other platform) machines without the increased overhead and licensing cost of a Windows DC (although you can get away with running a server core DC on as little as 512MB of RAM, I generally use 2GB).

In my case, I'm looking at purchasing a newer version of server, and just migrating the whole thing over, so I can RDP directly into the host, and maintain things - this was a good move however when I was operating on a tight budget - it should be pretty trivial to migrate my VM's later to another box.

Reply on news.ycombinator.com