When is a hypervisor 'not' a hypervisor?
Note: The following fix doesn't concern more recent versions of GNU/Llinux on Hyper-V. For instance, Ubuntu 16.04 LTS and above.
Abstract: Microsoft Hyper-V does not reliably host Ubuntu GNU/Linux virtual machines -- often not responding to network requests -- until a set of Hyper-V integration services is installed on the Linux machine.
For search discovery purposes: What's wrong with the GNU/Linux virtual machines on my Microsoft Windows Hyper-V virtual host? Why do the Linux machines not respond to network requests (ping, ssh, etc.) for a few minutes, while the Windows virtual machines do? It's a virtualized network card on a a virtual machine -- what could go wrong? Is the hypervisor, the system responsible for producing and maintaining the virtual environments, not working? Is it broken? Why is it failing? This is ancient technology: how could the hypervisor, the VMM (Virtual Machine Manager) be so broken? How could the culprit be Hyper-V? I would think that's the most stable technology imaginable.
Having built and worked with hypervisors since the early 1980's, I believed that a hypervisor was a hypervisor. It created a reliable virtualized environment.
But virtual machines have competed with much lighter-weight sandboxing and namespace isolation solutions for many years, especially with the advent of containers. That means that a modern hypervisor is not a traditional hypervisor. It's trying to optimize and pipeline resources, and it needs cooperation from the operating system on the virtual machine to even begin to compete with containers, which have no separate operating system at all.
That means: if you just install an operating system on a virtual machine, you need to make sure the OS knows which hypervisor it's working with. These are integration adaptations. There's no need to be an isolation purist. In fact, isolation is always virtualized in the computing world. We build computers to give us reasonably reliable isolation of logical spaces when we want them. That doesn't always work, but it works most of the time. But in reality there are all sorts of interconnections that are working hard to maintain this illusion of separation for us. Consider a web application with separate user accounts. That isolation is a construction. The exceptions and actual connections and commonalities (a user table, for example) are well-understood.
For Ubuntu GNU/Linux server 16.04 (Xenial) running on Hyper-V, if you want your virtual network to run reliably, you need to activate "hv", which is already installed in the OS:
Add the following lines to the /etc/initramfs-tools/modules file:
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
Then run:
update-initramfs -u
... and reboot.
Abstract: Microsoft Hyper-V does not reliably host Ubuntu GNU/Linux virtual machines -- often not responding to network requests -- until a set of Hyper-V integration services is installed on the Linux machine.
For search discovery purposes: What's wrong with the GNU/Linux virtual machines on my Microsoft Windows Hyper-V virtual host? Why do the Linux machines not respond to network requests (ping, ssh, etc.) for a few minutes, while the Windows virtual machines do? It's a virtualized network card on a a virtual machine -- what could go wrong? Is the hypervisor, the system responsible for producing and maintaining the virtual environments, not working? Is it broken? Why is it failing? This is ancient technology: how could the hypervisor, the VMM (Virtual Machine Manager) be so broken? How could the culprit be Hyper-V? I would think that's the most stable technology imaginable.
Having built and worked with hypervisors since the early 1980's, I believed that a hypervisor was a hypervisor. It created a reliable virtualized environment.
But virtual machines have competed with much lighter-weight sandboxing and namespace isolation solutions for many years, especially with the advent of containers. That means that a modern hypervisor is not a traditional hypervisor. It's trying to optimize and pipeline resources, and it needs cooperation from the operating system on the virtual machine to even begin to compete with containers, which have no separate operating system at all.
That means: if you just install an operating system on a virtual machine, you need to make sure the OS knows which hypervisor it's working with. These are integration adaptations. There's no need to be an isolation purist. In fact, isolation is always virtualized in the computing world. We build computers to give us reasonably reliable isolation of logical spaces when we want them. That doesn't always work, but it works most of the time. But in reality there are all sorts of interconnections that are working hard to maintain this illusion of separation for us. Consider a web application with separate user accounts. That isolation is a construction. The exceptions and actual connections and commonalities (a user table, for example) are well-understood.
For Ubuntu GNU/Linux server 16.04 (Xenial) running on Hyper-V, if you want your virtual network to run reliably, you need to activate "hv", which is already installed in the OS:
Add the following lines to the /etc/initramfs-tools/modules file:
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
Then run:
update-initramfs -u
... and reboot.