Well, I just realized that I had dived into talking about how to do things with Hyper-V without first taking the time to orient you on some of the terminology used. So I would now take the time to correct that. Note that many of these terms are not used in the user interface / documentation for Hyper-V. The reason for this is that from an operational "getting things done" point of view you do not need to know about most of this. However, once you start discussing architecture it becomes necessary to know about this stuff:
The hypervisor is to Hyper-V what the kernel is to Windows. The hypervisor is not all of Hyper-V, it is just the lowest level component that is responsible for interaction with core hardware. The hypervisor is responsible for creating, managing and destroying partitions. It directly controls access to processor resource and enforces an externally delivered policy on memory and device access. To give some perspective: the hypervisor is just over 100k in size, the entire Hyper-V role is around 100mb in size and a full installation of Windows Server 2008 with Hyper-V will be multiple gigabytes in size. Once you have installed the Hyper-V role the hypervisor is loaded as a boot critical device.
The virtualization stack is everything else that makes up Hyper-V. This is the user interface, management services, virtual machine processes, emulated devices, etc...
A partition is the basic entity that is managed by the hypervisor. It is an abstract container that consists of isolated processor and memory resources - with policies on device access. A partition is a lighter weight concept than a virtual machine - and could be used outside of the context of virtual machines to provide a highly isolated execution environment.
This is the first partition on the computer. Specifically this is the partition that is responsible for initially starting the hypervisor. It is also the only partition that has direct access to memory and devices.
The parent partition is a partition that is capable of calling the hypervisor and requesting that new partitions be created. In the first release of Hyper-V the parent and root partitions are one and the same - and there can only be one parent partition.
Child partitions are partitions that have been made by the hypervisor in response to a request from the parent partition. There are a couple of key differences between a child partition and a parent / root partition. Child partitions are unable to create new partitions. Child partitions do not have direct access to devices (any attempt to interact with hardware directly is routed to the parent partition). Child partitions do not have direct access to memory (when a child partition tries to access memory the hypervisor / virtualization stack re-map the request to different memory locations).
A virtual machine is a super-set of a child partition. A virtual machine is a child partition combined with virtualization stack components that provide functionality such as access to emulated devices, and features like being able to save state a virtual machine. As a virtual machine is essentially a specialized partition, I (and many members on the team) tend to use the terms "partition" and "virtual machine" interchangeably. But, while a virtual machine will always have a partition associated with it - a partition may not always be a virtual machine.
Guest Operating System
This is the operating system / runtime environment that is present inside a partition. Historically with Virtual Server / Virtual PC we would talk about a "host operating system" and a "guest operating system" where the host ran on the physical hardware and the guest ran on the host. With Hyper-V all operating systems on the physical computer are running on top of the hypervisor so the correct equivalent terms are actually "parent guest operating system" and "child guest operating system". Having said that, most people (apart from architectural die hards) find these terms confusing and instead use "physical operating system" and "guest operating system" to refer to parent and child guest operating systems respectively.
Emulated devices are the hardware that is presented inside of the virtual machine. If you have used Virtual Server / Virtual PC you will be quite familiar with this hardware. It includes things like a Intel 440bx motherboard and an Intel 21140 network adapter. These devices are handled through emulation that runs in the parent partition. The advantage of emulated devices is that most operating systems have in-box drivers for them and are able to install and boot using them. The disadvantage of emulated devices is that because they were not designed with virtualization in mind they do not perform well.
Synthetic devices are the new high performance devices that are available with Hyper-V. Here, rather than emulating an existing hardware device we expose a new hardware device that has been designed for optimal performance in a virtualized environment (I will not go into a performance discussion of synthetic versus emulated devices here - as that is quite a lengthy discussion and can wait for another day). Generally speaking you will never see reference to a "synthetic" or "emulated" device in our user interface as we have tried to hide this from the user as much as possible.
Most of our devices (IDE, video, mouse, etc...) support booting in emulated mode, but then switching across to synthetic mode once appropriate drivers are loaded. There are some exceptions to this though. On networking you have to choose to use a "Network Adapter" or a "Legacy Network Adapter". The former is a synthetic device while the latter is an emulated device. With storage the "SCSI controller" only exists as a synthetic device. And finally there are a handful of devices where performance is not really a problem (like COM ports) so we only offer emulated devices for them.
Integration services are user mode processes that run in the child guest operating system to provide some level of "integration" between the parent and child environments. Some examples include: time synchronization, child guest operating system shutdown messaging and backup support.
Integration Services Setup Disk
This is a CD image that contains the installer for both the integration services and the synthetic device driver. You use it to get these components on your virtual machine so that you can have the fastest / best user experience.
Now here there is even some contention inside the virtualization team as to the correct usage of this term. Some people use this term to refer to changes / intelligence in the guest operating system kernel that allow it to perform faster / with less overhead inside a virtual machine. While others use it to refer to synthetic devices and integration services as well. Those of us who use the broader definition will often use the terms "device enlightenment" and "kernel enlightenment" to differentiate between the concepts.
I personally fall into the first camp and when I say "enlightenment" I mean "kernel enlightenment". (There is a whole conversation around enlightenment as a concept, but I am leaving that too for another day).
Virtual Machine Snapshot
As discussed here - a virtual machine snapshot is a point in time image of a virtual machine that includes its disk, memory and device state at the time that the snapshot was taken. It can be used to return a virtual machine to a specific moment in time - at any time. Virtual machine snapshots can be taken no matter what child guest operating system is being used and no matter what state the child guest operating system is in.
Unfortunately the term "snapshot" is also used in the Windows world in the context of VSS. VSS snapshots are complete system backups that should be used for protecting your system against unplanned data loss / hardware failure.
This is simple. It is the squarish chip that you put in your computer to make it go. This is sometimes also referred to as a "package" or a "socket".
This is a single execution pipeline on the physical processor. In the "good old days" someone could tell you that they had a two processor system - and you new exactly what they had. Today if someone told you that they had a two processor system you do not know how many cores each processor has, or if hyperthreading is present. A two processor computer with hyperthreading would actually have 4 execution pipelines - or 4 logical processors. A two processor computer with quad-core processors would in turn have 8 logical processors.
This is the concept of how your logical processors correlate to your physical processors. For instance, a two processor quad core system and a four processor dual core system both have 8 logical processors - but they have different processor topologies.
A virtual processor is a single logical processor that is exposed to a partition by the hypervisor. Virtual processors can be mapped to any of the available logical processors in the physical computer and are scheduled by the hypervisor to allow you to have more virtual processors than you have logical processors.
That seems like a good set to start with. If there are some that I have forgotten - I will do another terminology post at some time in the future.