Hyper-V Program Manager
When I have talked to people about Hyper-V - I have often come across the sentiment that Hyper-V doesn't feel like a hypervisor based virtualization solution. You install Windows, enable a role and then have virtual machines - how is this different from the Virtual Server type experience?
So let me step you through this:
So what does this mean for the copy of Windows you initially installed on the physical computer? Well, unlike the virtual machines that you create after installing Hyper-V, this installation of Windows continues to have direct access to the physical hardware and memory in the system. However, the hypervisor is completely managing its access to CPU resource and system timers.
For the most part we have worked hard to not have this be exposed in the parent partition - but there are two interesting places where it shows up. The first is when it comes to accounting for CPU usage (as discussed in this post). The second is when it comes to looking at CPU capabilities. When the hypervisor launches it actually starts "lying" about the CPU capabilities to all the partitions (including the parent partition). It does this so that no software in the guest operating systems try to use CPU functionality that the hypervisor now controls. The most obvious capability that the hypervisor hides is support for hardware virtualization:
If you look at this screenshot you will see that I am running a virtual machine on Hyper-V - and must, therefore, have hardware virtualization support in my system. However a copy of securable in the parent partition is reporting that hardware virtualization is not available. This is because the hypervisor has loaded and is changing the information being reported here.
Does the hypervisor place on any overhead on the first Windows installation? Should the first installation only be used to manage the Hyper-V role or can it be used as a regular server too? For example, if I wanted to run three servers on one physical box, should I install the Hyper-V role on the first installation, then create three virtual machines, or should I create two virtual machines and use the first installation for other roles? (hope that makes sense?)
There's no "right" answer... it really depends on what you want to do with your virtual machine farm...
You might argue that SQL*Server should be installed in partition0 if it were going to provide database services to "many" machines; but you could argue that web or email might best be put in another partition.
Partition0 has direct access to the disks and file system, so there will always be lower overhead for it; but that said, the ability to move a virtualized machine from one host to
another might be more important.
It really depends on what the goals of virtualization are... and requires you think through and plan.
So what happens if the parent parition crashes (bsod for example). does it bring down the hypervisor? plus of course patches to to the parent partition might require a full restart?
a Core install with HyperV, remotetly manage it, and only use child parititions for real workload would provide the best potential for stability?
As I'm starting to move from Virtual Server 2005 to Hyper-V for my development testing needs (64-bit, mostly), I must say that the fact that Hyper-V is implemented as a hypervisor has no meaning to me. I see it as an unimportant implementation detail.
It does mean that there's no solution of having virtual machines on my Windows Server 2003 laptop. I currently do it with Virtual PC 2007, and it works great. Virtual Server 2005 would work just as well. But if I install Windows Server 2008 and add Hyper-V, then I lose the ability to sleep/hybernate - which I deem unacceptable. I may have to switch to VMWare when I really need 64-bit virtual machines.
In the aerly days of virtualization, I remember someone pointing that one of the differences between VMWare WS and VPC was the fact that, while VMWare emulated the processor, VPC actually shared it (that's why VMs saw our physical processor's speed, etc.). Hyper-V is sort of going into that direction, isn't it?
By the way, now that I'm writing, I hope some of you might have more info than me: what are the plans about virtualization for Vista (both x86 and x64)? Will there be a new VPC? Will there be a Hyper-V for Vista?
Hyper-V not feeling like a traditional hypervisor product is also a problem in my opinion. Multiple roles on your hypervisor is possible but doesn't seem to be logical to me, like for instance combining hyper-v with SQL like mentioned above.
What john mentions seems more logical to me, core install + hyperv.
VM Ware WS didn't and doesn't emulate the CPU, both it and VPC both use virtualize it. VPC-Mac had an emulated x86 processor.
Virtualizing the processor is faster than emulating one.
This may require a new thread. I want to talk about backup. Specifically, does the Hyper-V Writer (VSS) include file specifications for any SAN disks attached to a VM via iSCSI?
iSCSI disks attached to a VM (using internal configuration unknown to Hyper-V) may contain data that needs to be backed up. Yet, Hyper-V knows nothing about these disks.
I am also interested in the answer to the question of what happens when the first booted copy of windows, the partion0 or parent, crashes. What about BDOD, hard lock, etc? How do we step in and reset it without resetting the hypervisor?
Stuart - Yes, Hyper-V does impact the performance of software running in the parent partition. You should not run other server workloads in the parent partition.
John - If the parent partition crashes - the whole system goes down. Yes - we do recommend that the parent partition be Server core with no other workloads running to increase reliability.
oreidomar - I cannot talk about future product plans.
rwright - Disks that are directly connected to a virtual machine (as opposed to VHDs) will not be backed up by VSS support in Hyper-V.