Why is that a hypervisor, which alledgedly needs to be on physical hardware, can be deployed within a VM?
For example, XenServer (the actual hypervisor) can be deployed in an ESX VM?
Why is this possible (Although not a good idea for many reasons, but still works).
Also, why do people say a hypervisor needs physical hardware (from an architectural point of view, rather than obvious performance reasons).
Thanks
A bare-metal hypervisor (eg ESX, Hyper-V) is simply an operating system designed to control and monitor the access to the hardware. So naturally, a hypervisor within a virtual machine would be controlling and monitoring access to the hardware it has access to. This works because the virtual hardware looks exactly like the real hardware.
Paravirtualization (eg Xen) on the other hand, does not pass the hardware architecture to the virtual guests, but rather provides an API to use resources. Thus, conventional operating systems (and hypervisors) would not be able to run on a paravirtualized system.
It depends on the type of hypervisor. There are hypervisors that can be deployed within other hypervisors. There are a lot of gotchas, and hardware support under 64-bit is not good. I have to emphasize that you would never do this besides for testing -- even then, it's only useful for testing certain functionality (like vMotion or HA on the VMware side). It doesn't give you any indication of how well the software performs in a production environment.
First, you need to understand x86 privilege levels (rings): http://en.wikipedia.org/wiki/Ring_(computer_security)
Typically, an operating system (with its privileged access to hardware) will run in Ring 0, and its user-level programs (which must proxy hardware interaction through the OS) will run in Ring 3. When a program makes a system call, it passes a message to the operating system asking it to run a particular function in its Ring 0 space and return the results of that to the Ring 3 program.
When you implement virtualization completely in software (without hardware assistance like Intel VT-x or AMD-V), what you essentially do is inspect the privilege levels of the code inside the running VM. In VMware, this technique is called binary translation. Any code running in Ring 3 continues to run in Ring 3, unmodified. Anything which runs in Ring 0 is run in Ring 1 instead, with the Ring 0 hardware access proxied through the hypervisor's virtual hardware. The virtual hardware is just a set of software that tells the host OS to do something in its Ring 0 space.
Certain hardware does not provide support for binary translation, because it doesn't support the ring levels necessary to make it happen. Notably, Rings 1 and 2 do not exist in the 64-bit modes of most modern x86 processors (some AMD CPUs do support it, but Intel does not). Therefore, binary translation is typically restricted to a 32-bit guest OS.
Since you're already using Ring 1 when you're using a hypervisor with binary translation, you can't run a BT hypervisor inside of another one. (Okay, so hypothetically someone could write a hypervisor that uses Ring 2 when it, itself, is being virtualized. It's such an edge case that I don't think anybody's done it.)
Paravirtualizing hypervisors, like Xen, work under a similar premise. Paravirtualized hypervisors use specially modified guest kernels that, instead of running in Ring 0, know they're not running on physical hardware and are coded to use special methods to talk to the hypervisor. Since paravirtualization works entirely within ring levels already in use by the operating system, I believe you should be able to run arbitrarily-nested levels of paravirtualized hypervisors as long as the hypervisor doesn't itself require any direct hardware access. There are obviously practical limits to how deep you can go, and as noted, performance is not going to be good.
Hardware extensions, on the other hand, work the opposite way from binary translation -- they provide a super-privileged hypervisor level, or Ring -1 (sitting one level below Ring 0), which runs all of the Ring 0 code unmodified. When these instruction sets are in use, Ring -1 provides an environment in which the Ring 0 operations of the virtual machine are caught and handled by the hypervisor without any analysis of running code.
You cannot run two hypervisors using hardware extensions at the same time, even if you're trying to run them side-by-side. For example, you cannot run Windows XP Mode in Windows 7 if you are already using VirtualBox to run a virtual machine using hardware virtualization support.
What this leaves us with is that you can run a binary translation hypervisor inside a hypervisor using hardware virtualization, but not the other way around. Additionally, the hypervisor-in-a-hypervisor will generally only be able to run 32-bit guests, but the performance impact is often not as substantial as some other posters have suggested. (Applications that need heavy memory access, like database servers, will still suffer, because they have to go through two sets of virtual page tables.) Most hypervisors will detect when they're being run inside another hypervisor and will refuse to run. Some hypervisors will work just fine in a testing capacity; you can run several VMware ESXi instances under VMware Workstation, for example (but you can only use BT mode in any ESXi virtual machines hosted under VMware Workstation).
Xen does not perform binary translation -- it either uses hardware-assisted virtualization or performs paravirtualization. It is possible to run Xen paravirtualized underneath another hypervisor, but you cannot run Xen-under-ESX virtual machines using full hardware virtualization in this way.
Hope this helps.
You can't run Hyper-V in any virtual machine. It must run directly on the hardware. You can install the Hyper-V role under some virtualization systems but you cannot run a vm. You may be able to run the Hyper-V Manager program however.
Why is that a hypervisor, which alledgedly needs to be on physical hardware, can be deployed within a VM?
IT CAN NOT - with good performance.
Also, why do people say a hypervisor needs physical hardware (from an architectural point of view, rather than obvious performance reasons).
Why are tired round?
Hypervisors normally use the hardware virtuaiaztion features. hich are not supported from a client application WITHIN the virtual layer. Basically the processsor has a work mode for the hypervisor, and one for the normal OS, and the normal OS can not switch back to thypervisor mode.
Without hardware virtualization you have to simulate this stuff an d- acutally - intterpret a lot of processor instructions (through a pogram) with the result of being a lot slower than the hardware level.
