Solution 1:

Could someone explain how it is different? Is there a performance difference? Any reason for me to choose one instead of the other?

As the other answer you have already explains, there are some architectural differences between the two projects.

Roughly speaking, where an Intel VT hypervisor is concerned, to activate the hypervisor you run (in assembly) a special sequence of instructions, culminating in VMXON. This enables the hypervisor mode.

Part of that work involves defining virtual machines in terms of their extended page tables or the AMD equivalent. This is like the ordinary task of setting up page tables (what memory maps where) except you do it for whole memory regions for virtual machines. Previous VM technology just trapped VM Exits for this purpose which are essentially like fancy hardware interrupts.

How does this refer to architecture? Well, you have two choices building a hypervisor:

  1. Build a standalone hypervisor that sets up the virtual machine monitor and then waits for guest operating systems. Usually, it either contains enough of its own operating system to manage the VMs, or supports a privileged guest. For example, the Xen Hypervisor includes a "Dom0" "guest" that has the ability to manage the hypervisor.

  2. Build a hypervisor as part of an existing kernel, for example as a kernel module. Code can be installed as a virtual machine monitor in Intel VT at any point during an operating system's lifetime (assuming sufficient privilege) and also removed. As such, the hypervisor code simply sets up the necessary required space in-memory as needed.

Practically, the difference for the end user would be that you cannot unload the hypervisor if it is of the first kind without a reboot. This is because it acts like an operating system in its own right. Hyper-V acts like this - if you have Hyper-V installed you cannot then install VirtualBox, for example, because both cannot share the virtual machine monitor space (since Hyper-V already has it). In order to unload the hypervisor, you need to reboot.

So to put it simply: if you have Hyper-V installed, even if you have no VMs running, you will not be able to use any other virtualization product. This is not the case for Virtual PC.

Now, performance. On Intel VT-like systems, whether you load the OS or the hypervisor first likely makes little difference performance-wise, since this is only a CPU bound area and if you're already using CPU hardware-assisted virtualisation, you're as fast as you can get anyway.

Performance wise, the differences in virtualisation come from techniques such as paravirtualisation and the use of IOMMU/DMA re-mapping. In short, the OS memory/CPU order of organisation won't make as much difference as whether or not you can efficiently virtualize things like hard disks, graphics cards etc.

It very much sounds from this blog post that Hyper-V has had problems in the past with consumer-type virtualisation concerns: graphics, sound etc. I've not run Hyper-V needing these things, so I can't comment as to whether they're still an issue, but it may be worth investigating.

Solution 2:

Hyper V will provide better performance than say, Windows Virtual PC

http://en.wikipedia.org/wiki/Hypervisor

Robert P. Goldberg classifies two types of hypervisor:[5]

Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. A guest operating system thus runs on another level above the hypervisor.

This model represents the classic implementation of virtual machine architectures; the original hypervisors were the test tool, SIMMON, and CP/CMS, both developed at IBM in the 1960s. CP/CMS was the ancestor of IBM's z/VM. A modern equivalent of this is the Citrix XenServer, VMware ESX/ESXi, and Microsoft Hyper-V hypervisor.

Type 2 (or hosted) hypervisors run within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware. KVM, BHyVe, and VirtualBox are examples of Type 2 hypervisors.

Wikipedia explains it clearly