4 ms·

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.

• rbanffy 9y ago
  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.
  • Aloha 9y ago
    I've never really had any issues with it, and I'm doing stuff I consider to be a little esoteric, like volume passthru.
    • teilo 9y ago
      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.
      • Aloha 9y ago
        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.
        • teilo 9y ago
          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.
          • Aloha 9y ago
            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.
  • teilo 9y ago
    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.
• DKnoll 9y ago
  What did you find painful about setting up Hyper-V Server?
  • Aloha 9y ago
    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.
    • DKnoll 9y ago
      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).
      • Aloha 9y ago
        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.