5

While reading different materials on different subjects every now and then I come back upon the question: How virtual really is virtualization? With "virtualization" I mean things like Virtual PC and VMWare, which allow you to run an guest OS. In particular, what I don't understand is:

  • Does the virtual machine provide an environment which is fundamentally indistinguishable from a physical machine? Of course, there will be some practical differences (like hypervisor call escape hatches, dummy hardware component names, etc.) which allow the detection of a virtual machine, but will there be any incompatibilities?
  • If the environment is fully compatible with a physical machine, then are nested virtual machines possible?
  • If not, does that mean that the guest OS has to be specifically adapted for running inside a virtual machine? If so, then does that mean that most of today's OS'es have already been adapted for most VM vendors?
  • Are these things different for software-based virtualization vs hardware based?
  • What exactly is the difference between software-based virtualization and hardware-based?
1
  • Ehh... this question would have been SO much better on Stackoverflow... But, if you insist...
    – Vilx-
    Jan 25, 2011 at 9:51

6 Answers 6

6

As far as I know:

  • There were studies on the possibility of an "undetectable rootkit" where a malicious hypervisor would sit between your computer and the hardware. Security firms (and CPU vendors) were enraged that someone devised something like that and told no one could detect it, so they actually came with a way using timing functions and comparing the results with an external source. So virtualization is almost undetectable, but if you pay really close to small details and you have an external reference, there are ways to figure out you're being virtualized. It shouldn't cause any incompatibility, though.
  • It's not. Your virtualized CPU doesn't have the same capabilities your physical one has. The Intel virtualization instructions are available only to the host OS, for instance. That doesn't mean, however, that you cannot have a virtual machine inside a virtual machine: it just means it's gonna be damn slow.
  • OSes don't have to be adapted for virtual machines. It rather goes the other way around.
  • Yes, they are to some extent. Software virtualization will always work. Hardware virtualization usually isn't transitive (guest OSes can't use hardware virtualization to host more guest OSes).
  • There must be more to that, but I think that's a good start.
2

Let me answer point by point:

1 Does the virtual machine provide an environment which is fundamentally indistinguishable from a physical machine? Of course, there will be some practical differences (like hypervisor call escape hatches, dummy hardware component names, etc.) which allow the detection of a virtual machine, but will there be any incompatibilities?

If you ignore "hypervisor call escape hatches, dummy hardware component names", all other different are consider bugs. ... except, see below.

2 If the environment is fully compatible with a physical machine, then are nested virtual machines possible?

This depends. If you use hardware virtualization, You can't run hypervisor under hypervisor. (in theory, you can emulated that too, but nobody care enough to do those messy work)

3 If not, does that mean that the guest OS has to be specifically adapted for running inside a virtual machine? If so, then does that mean that most of today's OS'es have already been adapted for most VM vendors?

You have got it reveresed. We got OS before virtual machine. Virtual machine adapt for OS, not the another way round. (there are some exception, e.g. old version of Xen. But this is exceptions)

4 Are these things different for software-based virtualization vs hardware based?

see 2.

5 What exactly is the difference between software-based virtualization and hardware-based?

see 4.

2

Virtual machines attempt to provide environment that is good enough to run the guest OS and applications. It is virtually impossible to provider environemnt that is indistinguishable from physical since there are timing effects that are very hard to hide (at least in a VM that runs efficiently)

Nested virtual machines are possible with VMs that are purly emulated (e.g. Bochs), but Virtual PC and and VMware use some hardware support that is not designed for nesting.

Software-based virtualization emulates every CPU instruction (sometimes software based solutions use Ring-1 to natively run Ring-0 code as an optimization and this trick cannot be nested).

Hardware-based virtualization uses a special mode in the processor designed to pass control to a Hypervisor and set an additional level of page tables.

2

As far as the guest OS knows, it's running on real hardware. The whole point of virtualisation is that you don't have to change anything on the guest.

VMWare (for example) provides tools and drivers to load into the guest but they're not necessary in an isolated machine. They make drag-and-drop between host and guest a possibility and some other neat features but they are not required to successfully run a guest itself.

IBM actually pioneered virtualisation with its VM (now z/VM) product which can successfully run other copies of z/VM, running yet more copies of z/VM running z/OS and zLinux.

Of course there may be some limitations on the actual VM implementation, the classic example being VMWare inability to run OS/2 even though that will run on a real CPU just fine.

But that's a product limitation, not a virtualisation concept one.

In terms of hardware/software differences, hardware virtualisation is just using some aspect of the actual CPU (or other hardware) to assist. Pure software virtualisation is really just emulation (and usually horribly slow compared to the alternative).

1

AFAIK virtualisation software emulates the HAL (hardware abstraction layer) seamlessly so the guest OS has no idea the difference. ie: normal OS's are used.

0

Does the virtual machine provide an environment which is fundamentally indistinguishable from a physical machine? Of course, there will be some practical differences (like hypervisor call escape hatches, dummy hardware component names, etc.) which allow the detection of a virtual machine, but will there be any incompatibilities?

Hardware accesses still go through the host OS.

PC operating systems have been decoupled from most hardware for a long time now. Windows and Linux both employ drivers that are the proxy for hardware access. Because of this, it's possible to provide "paravirtualized" drivers that are a proxy to work in a virtual environment, making things a lot easier to implement than emulation - where you'd have to design programs that 100% replicate all the weird and sometimes undocumented behavior of CPUs and hardware.

If the environment is fully compatible with a physical machine, then are nested virtual machines possible?

The VMXON instruction that "turns on" the CPU virtualization will not work when the CPU is "in" a virtual machine. If this happens, a "VM exit" occurs - meaning control is passed back to the hypervisor - and the host OS must now decide what to do (typically emulating an "illegal instruction" exception). It's possible for the host OS to emulate this instruction and the rest of the CPU virtualization behavior if desired (it would be difficult and slower).

If not, does that mean that the guest OS has to be specifically adapted for running inside a virtual machine? If so, then does that mean that most of today's OS'es have already been adapted for most VM vendors?

See my first point. Paravirtualized drivers for VMWare and other hypervisors exist. The core OS itself doesn't really have to change unless A) it's something tightly coupled to specific hardware such as DOS and B) it's decided that changing the OS is better than emulating the hardware it expects.

Are these things different for software-based virtualization vs hardware based?

Software based virtualization is slower and probably less secure.

What exactly is the difference between software-based virtualization and hardware-based?

Simplifying a bit, x86 CPUs for a long time have had generally two privilege levels, user mode and supervisor, or kernel mode. Hardware virtualization support adds a privilege level higher than supervisor, i.e. hypervisor. An example of a difference is that the MMU that a CPU's OS uses to manage memory pages is extended to allow hypervisors to work with it. This makes it easier for a hypervisor to allocate and isolate memory for a specific VM. IOMMU is also a hardware feature that also provides a lot of facilities that make virtualization more efficient.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .