HyperV Partitioning
-
@travisdh1 said in HyperV Partitioning:
You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.
My point is that things in the IO path go through that VM. They didn't want to write a full IO driver stack for Hyper-V so they have the VM for that. Compute/Memory doesn't go through it (that I know of), but network and disk IO do. (Otherwise Perfmon wouldn't work as a monitoring solution on the host).
AFAIK only ESXi uses a microkernel that has a fully isolated management agent plane (It's actually just a busybox shell).
-
@travisdh1 said in HyperV Partitioning:
@storageninja said in HyperV Partitioning:
@tim_g said in HyperV Partitioning:
Windows Server runs on top, and every VM runs beside it. The only thing Windows Server can do, is manage the VMs using various components.
The Hyper-V Hypervisor is only 20 MB. It runs in memory. Not sure what you mean by "god awful footprint"?If that VM is a pure control plane, then I can reboot or patch it without impacting network or storage IO on the other VMs in the same way I can restart management agents on ESXi or KVM right? If Hyper-V is handling the network and storage traffic 100% then surely it must have its own driver stack, and not be dependent on the management VM for these functions, right?
Unless this has changed, you lost every VM on a host from a simple reboot of the management VM previously.You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.
XenServer does the same thing too.
-
@black3dynamite said in HyperV Partitioning:
@travisdh1 said in HyperV Partitioning:
@storageninja said in HyperV Partitioning:
@tim_g said in HyperV Partitioning:
Windows Server runs on top, and every VM runs beside it. The only thing Windows Server can do, is manage the VMs using various components.
The Hyper-V Hypervisor is only 20 MB. It runs in memory. Not sure what you mean by "god awful footprint"?If that VM is a pure control plane, then I can reboot or patch it without impacting network or storage IO on the other VMs in the same way I can restart management agents on ESXi or KVM right? If Hyper-V is handling the network and storage traffic 100% then surely it must have its own driver stack, and not be dependent on the management VM for these functions, right?
Unless this has changed, you lost every VM on a host from a simple reboot of the management VM previously.You expect Microsoft to do things rationally, or correctly? That'd be a nice change of pace.
XenServer does the same thing too.
Where did I claim that anyone gets it right? Looks to me like only ESXi get's it with this particular issue.
-
You can restart the toolstack on XenServer and not interfere with the daily operations of the VM's.
So um. . .
-
@storageninja said in HyperV Partitioning:
My point is that things in the IO path go through that VM. They didn't want to write a full IO driver stack for Hyper-V so they have the VM for that. Compute/Memory doesn't go through it (that I know of), but network and disk IO do. (Otherwise Perfmon wouldn't work as a monitoring solution on the host).
I think you have some misconceptions or misunderstandings regarding the Hyper-V architecture and components... or Hyper-V stack...
This is not true at all, as it actually depends on the OS running in a VM.
Operating systems that already have the integration components baked into their kernel (Enlightened VMs) use their own Hypercalls to communicate directly to the hypervisor, then to the physical hardware.
Only for non-supporeted (older) operating systems, does the "parent partition" intercept the VM communication, emulating Hypercalls. In this case, there are performance degradations as the management OS needs to work as a bridge to allow the VM to access the hardware.
To note, this is why it's important for VMs to be running with the latest IC version.