VIRTUALBOY BLOG
Hyper-V is a very cool technology. It's also a very complex technology, with a lot going on under the covers. When I deliver sessions on Hyper-V, and I talk about the architecture, it's a difficult concept to discuss quickly, hence, hopefully, this post will go some of the way to trying to explain the Hyper-V architecture in an easy to remember, and digest, way!
So, let's start with the Microkernalised approach to virtualisation. The diagram on the left shows the Hyper-V hypervisor. What is the hypervisor? Well, its a layer of code that runs natively on the hardware - it's the lowest thing on your system, and it's responsible for owning the hardware, and doing hardware and resource partitioning. The main difference between this and a monolithic hypervisor such as VMware's ESX, is the location of the drivers and location of some core operating system components. As you can see, in Hyper-V, the drivers exist in the actual partitions themselves, rather than actually in the hypervisor. This means that we can massively reduce the size of the hypervisor. In fact, Hyper-V's hypervisor is around 600kb in size. That is a small bit of code. Interestingly enough, this is a small bit of Microsoft code.
That's right. It's 100% Microsoft - there's no 3rd Party code gone into this platform. There are no operating systems components in the hypervisor. It's just a thin slither of reliable, and secure code. Now, certain people in the industry have questioned Microsoft's driver model, based on previous experiences with Windows drivers, and the fact that anyone could pretty much knock up a driver and it would be 'accepted' by Windows. I'd have to disagree with x64 drivers and Windows Server 2008. Microsoft have worked incredibly hard to provide mechanisms and structured programs for device manufacturers to produce top quality drivers, and sure, some will slip through the net, but as the mechanism evolves, this will be reduced and reduced. When it comes to x64 drivers, they all have to be signed, which means they have to go through even more testing to ensure they are of a good quality, and we've made loads of guidelines available for driver-writers (if that's what they are called!) here: http://www.microsoft.com/whdc/driver/64bitguide.mspx so it's not like they have to find their own way around the topic. Anyway, I digress.
You may or may not have had the chance to read a whitepaper about 'Blue Pill' which is a hypervisor rootkit security whitepaper. It's naming is in reference to the Matrix, where in the movie, if you take the blue pill, you exist in the computerised world, and continue to be controlled by the computer and you have no idea you are being controlled...The concept here is, if someone was to take control of your hypervisor, with it being the lowest element on your system, the elements above the hypervisor would not know they were being controlled, and would find it very difficult to detect. With this in mind, keeping core operating systems bits out of the hypervisor, and keeping it trim, clean and secure, also brings a strong level of reliability.
So, that's enough about the hypervisor as such, but lets look at the rest of the architecture:
So, when it comes to the hardware, it needs to be hardware with Intel-VT or AMD-V hardware assisted virtualisation technology, it needs to be x64 (not Itanium), you also need to enable the 'No Execute Bit' in the BIOS too. This is used to create a more secure environment. The diagram above is an installation before enabling Hyper-V. What you see on the left hand side of the diagram could be a full GUI version of Windows Server 2008, or it could be a Server Core installation. Advantages of Server Core include smaller footprint, lower attack surface, and reduced patching to name but a few. When we enable Hyper-V:
The hypervisor now slides under the OS, and this now becomes the lowest part of your system. Remember, it's a very thin, secure hypervisor. It's like a thin layer of veneer on the hardware. Enabling Hyper-V also brings the bits in the purple boxes:
The VM Worker Processes are individual processes spawned for each virtual machine, and are designed to handle things like emulation...
As you can see, I've added 2 virtual machines (child partitions) here to explain VM Worker Processes a little further. You can see that the 2nd VM is a non-hypervisor aware OS, which means that the hardware it sees, needs to be emulated. This is the old IO model, used in Virtual Server and Virtual PC. Why is emulation good? It's good because it emulates known hardware. Known hardware such as 440BX Chipset Motherboard, a DEC Ethernet Controller card, and more. These examples are pieces of hardware that are very standard in the industry, and nearly every operating system under the sun understands. Microsoft or otherwise! Downfall of emulation is the cost in terms of an IO perspective. If there is an app running in the emulated VM, say, Excel, and it's wanted to save a 100kb file down to the hard drive. What happens is, is that Excel tries to write down into Kernal mode - it's not aware that's its running on a hypervisor and thinks it has direct access to the hardware. So, what we have to do, is do a trap to grab that request, bring it over to the Parent partition, into Kernel Mode, up into User Mode, into the VM Worker Processes, and that's where the emulation happens. Now, to give a crude estimate, but for a 100kb write, it takes about 80 traverses from the User Mode on the Child Partition, down into Kernel Mode, up into Kernel Mode on the Parent, and up into User Mode and the VM Worker Processes, and back again to make that 100kb write. So, inevitably, there's a performance hit with this type of virtualisation, but, on the flip side, you have a broad range of operating system support, such as below:
If you now look at the other Child Partition, (in this case, with Windows Server 2003 / 2008 listed as the OS), this VM is not using emulation. It's using the VSP, VSC and VMBus architecture. This is the Virtual Service Provider, Virtual Service Clients, and they communicate over the high speed 'In Memory Bus'; VMBus, that we've created. It's 100% in memory, and not physically tangible in any way. It's been designed for IO traffic. So, effectively, the VM is writing directly to a driver (which is a VSC), and this information transfers directly to the VSP over VMBus (jumps back and forth a few times), and then onto the hardware below.
So, to expand on the VSP/VSC relationship, as you can see, we have the Parent partition on the left, and the hypervisor aware Child Partition on the right, split into User (top) and Kernel (bottom) modes. The Orange/Yellowy colour you can see, are all Hyper-V related bits. So, on the right hand side, the application tries to do a write, via the Windows File System, Volume, Partition and on to the Disk. If you're using emulation, you'd keep going down, across and up to the VM Worker Processes (not using VMBus) and it would go back and forth, back and forth, before it makes it's way to the StorPort MiniPort driver, and down to the hardware.
Now, with VSP/VSC, you work your way down, and it hits the VSC, goes across the VMBus to the VSP, still in Kernel mode here - there has been no need to go into User mode to handle this. Every time you go between User/Kernel mode, you take a performance hit, and because you are going back and forth, quite a few times in emulation, you take quite a few performance hits. This doesn't happen in the VSP/VSC world. Once the data is over at the VSP, it writes directly to disk, and then down to the hardware. Very fast and very performant. So, you get a very performant guest operating system, providing it knows it's running on the hypervisor. This reduces down the number of operating system choices by quite a way - right now, Windows Server 2008 and 2003 (with SP2), XP SP3 and Vista SP1 too.
What we're also hearing from customers is that you'd like a single platform to virtualise not only Microsoft OS's, but also Linux OS's, and that's where the partnerships with companies like Citrix, and Novell come in.
So, as you can see, we have 3rd type of Child Partition, namely, the Xen-Enabled Linux VM. This could be Novell SUSE SLES 10 SP1 as an example. So, this VM is running the Linux Kernel, and we've worked closely with the relevant organisations' to write the relevant VSC's and Hypercall Adaptors, that ensure that calls for hardware made by Xen-Enabled Linux VMs are handled in the most optimal way, rather than pushing them down the emulation route, as described earlier. This means certain Xen-Enabled Linux VMs really will be first class citizens on the Hyper-V platform. I'm sure, as time goes by, you'll find even more OS's come along with the ability to take advantage of the VSP/VSC architecture, as it really is the way to go :-)
That's about it - hopefully that's helped you understand the architecture, I know it's helped me by getting it off my chest!
Microsoft Licensing is complex. I think most people accept that!
Since September, the licensing and response management teams have been working together to publish the answers to your top licensing queries. Every month, these FAQs are put together based on calls and emails to our customer service team, so we know they will address topical questions and help you to understand Microsoft licensing. Think about it, if you have a question, chances are someone else has that very same question too, and they may have even asked it on this site already!.
We have recently re-designed the FAQ pages to deliver a significantly improved user experience. And we’ve also introduced an RSS feed that you can sign up to so you know when the content is updated. You can now see the “hot FAQs” at a glance and browse the rest by product or agreement type.
There are 2 separate websites; one for licensing queries where there are less than 250 PCs, and one for where there are more than 250 PCs! I guess if you have bang on 250, you'd go to the first one :-)
If you can’t find an answer to your licensing query here, please call our helpline on 0870 60 10 100 and select the business option, then option 3 for licensing. Alternatively, email licensing@microsoft-contact.co.uk - someone will respond to your email within 48 hours!
If you are doing anything with Server Core in Windows Server 2008, you'll know that there are always certain tasks you need to do upon installation to enable things like remote connection, pinging etc etc. Now, doing this from the Command Line is all well and good, if a) you understand it and b) you want to dedicate a little more time to doing the job.
Now, for those 'Wizard-lovers' among you (cue Harry Potter jokes), there's a great tool that's been developed to give you a small GUI within Server Core, to enable you to do those "little jobs" such as:
The Core Configurator enables you to do all those 'little jobs', quickly and easily! You can read all about it, see screenshots and download it, from here: http://blogs.microsoft.co.il/blogs/guyt/archive/2008/03/22/windows-server-core-coreconfigurator-to-the-rescue.aspx
Core just got a whole lot easier! :-)
Well, SCVMM 2008 Beta & Hyper-V RC0 had a great time together, however, some of the major interface changes that have gone into Hyper-V RC1 mean that RC1 and SCVMM 2008 Beta are on a bit of a break.
Fear not, as Rakesh details on his blog, the relationship will be back on fairly soon :-) In the mean time, I'd choose one or the other, and wait until the patch is available.
Not particularly new news, but it's been sat in my inbox for a while, and you may still find it useful.
One of my demos I often show around Windows Server 2008 is Server Core; a scaled down version of the OS with a command line interface for local management. Now, being from the School of GUI whilst growing up with technology means that scripting at the command line isn't in my comfort zone, which means it's important to provide powerful alternatives. In the case of Windows Server 2008 and Server Core, I could simply go to another Windows Server 2008 box (GUI version) and manage the Server Core box remotely (providing I've opened up the relevant ports in the firewall). This, however, isn't always convenient, especially if I spend most of my working day working on a client operating system, which in this case, would be Vista SP1.
So, with that, it's useful to learn that there is a tool that can be installed on Vista SP1 (x86/x64) which allows remote management of a Windows Server 2008 machine. So, what does it allow you to manage?
Role Administration Tools:
Feature Administration Tools:
The tools in the following list are fully supported managing Windows Server 2003 servers as well:
Download: Remote Server Administration Tools (x86)
Download: Remote Server Administration Tools (x64)
There are a few common questions being asked around what is required to run RSAT and what it actually replaces:
Q. Is RSAT the next version of ADMINPAK.MSI?
A. Yes. As ADMINPAK.MSI provides IT professionals the ability to remotely manage their Windows Server 2003 servers, RSAT provides updated functionality for Windows Server management from computers running Windows Vista with Service Pack 1. All RSAT tools support the management of servers running Windows Server 2008; some of these tools also support the management of servers running Windows Server 2003, and thus can be considered a replacement for ADMINPAK.MSI.
Q. Will RSAT run on the version of Windows Vista with no service packs installed?
A. No. RSAT requires Windows Vista with Service Pack 1.
RSAT is also available in the following languages:
Happy Managing! :-)
XP SP3 has been released into the public domain after a short delay. Get all the info, and the updates themselves, by following this link:
http://technet.microsoft.com/en-us/windowsxp/0a5b9b10-17e3-40d9-8d3c-0077c953a761.aspx
There's also an interesting whitepaper available, entitled Windows XP Service Pack 3 Overview, which you can pick up from here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=68C48DAD-BC34-40BE-8D85-6BB4F56F5110&displaylang=en
My favourite improvement within XP SP3 is the Network Access Protection integration:
"NAP is a policy enforcement platform built into Windows Vista, Windows Server 2008, and Windows XP SP3 with which you can better protect network assets by enforcing compliance with system health requirements. Using NAP, you can create customized health policies to validate computer health before allowing access or communication; automatically update compliant computers to ensure ongoing compliance; and optionally confine noncompliant computers to a restricted network until they become compliant. For more information about NAP, see Network Access Protection: Frequently Asked Questions."
This is something I'm really excited about - Virtualisation of desktops. Now, it's not the silver bullet that everyone thinks, and it's important to understand the licensing implications etc, plus I'm always in favour of a TS solution over VDI in terms of return on investment, but that said, there's something cool about virtualisation of your desktops, and some even cooler stuff taking place around the broker, that sits in between the end user's access device, and the virtual desktop in the datacenter; a component that Microsoft doesn't make itself...
Enter our Partners - Partners like Citrix, with the up and coming Citrix XenDesktop platform, but also Quest Software, with their Provision Networks Virtual Access Suite. I'm excited about both, and I'm keen to get some hands on time with each so I can start talking to our Partners about the opportunities of an integrated solution around VDI and Hyper-V.
There's an interesting article on InformationWeek and don't forget to check out the comments - there's a few Citrix fans (and rightly so) having a few things to say around the Quest offering, and vice versa (again, and rightly so!). I'm staying impartial, as I haven't used either, and being new to their technologies, ease of administration will obviously come into it.... :-)
James and Andrew from my team have been busy with the video camera (careful :-)) recording some more interesting Partner-TV videos. The latest series of video's are focusing on System Center; Microsoft's management platform. The guys have recorded and produced 2 video's so far, and there are a few more to go yet!
Their first video discusses System Center Configuration Manager...
While the second video discusses System Center Operations Manager...
A word of advice - don't press play on both of them at once :-) and another, make sure you keep tabs on the Partner TV blog - it's a great source of information!
You'll notice, from the image above, that Windows Server 2008 RTM is already listed as SP1. Is this a good thing? I think so. Iain McDonald, of the Windows Server team, agrees, and explains how the Windows Server / Windows Client relationship is better now than it's ever been...
http://blogs.msdn.com/iainmcdonald/archive/2008/02/15/windows-server-2008-is-called-sp1-adventures-in-doing-things-right.aspx
How do you deploy Windows Server? With Windows Server 2008, I typically install from the DVD, then, once complete, I connect to Windows Update, get the latest patches, then, I'll typically enable the Hyper-V role in Server Manager, reboot the machine, and then, and only then, I'm good to go with my 'Hyper-V Enabled' Windows Server 2008 machine.
OK, so that process, typically, would have taken about 30-45 minutes. What I could then do, before creating any Virtual Machines, is Sysprep the Operating System, then use a technology such as ImageX, or Ghost, to capture an image of my 'Hyper-V Enabled' Windows Server 2008 OS. This image could then be deployed onto another piece of hardware, and in theory, after applying that image, when I boot up Windows Server 2008, I should just be able to start creating Virtual Machines, as Hyper-V was already enabled in the image, right?
Wrong.
Doesn't quite work like that. Think about it, when you first install Windows Server 2008 (onto the hardware), the boot configuration datastore is created and updated etc, and then the OS boots for the first time. When you enable Hyper-V, you are placing a hypervisor between the OS and the hardware, so the boot configuration datastore is updated accordingly, so that when you boot this OS subsequently, the hypervisor starts automatically, and you can happily create virtual machines.
If you are applying a 'Hyper-V Enabled' image, you are laying down the OS, and the hypervisor layer in one go, so you have to execute a short script from the command line (or include it in your unattend file as a post installation script) to update the boot configuration datastore. The script is:
Bcdedit /set hypervisorlaunchtype auto
That's it! So, when you subsequently boot that OS, the hypervisor is correctly set up to run (providing the hardware you have applied the image to has Intel-VT or AMD-V, and DEP/Disable Execute Bit enabled).
I'm sure this will be listed in the final documentation, but at least now you know! It caused much head scratching with myself and a customer a few days back!