Steven Sinofsky and Jon DeVaan (who’s office is about 5 doors down from mine… I wonder if he can hear me yelling at my test machines) have just started a new blog called Engineering Windows 7.
There isn’t a lot of information over there right now, just a few introductory posts outlining the rules and the purpose of the blog, but I’d imagine that there will be some pretty good information going up on that blog as we approach WinHEC and PDC 2008.
If you’re interested in Windows 7, you should probably add this blog to your RSS aggregator.
Stay tuned here, as well. Once we get some information about Seven out there, I’ll be posting talking about it and how it relates to Virtualization.
Fun times are ahead, everyone.
I haven’t updated my three part series about different ways to install Hyper-V for our RTM release. I’ve been working on getting some step-by-step videos created, but it’s always been on the back burner, and I was waiting to update the posts until I had the videos ready.
Well, a discussion on an internal DL yesterday lit a fire under me, so now I’m going to sit down and do this. The videos aren’t done yet, but I’ll add them when they are.
Since not much of the original content has changed, I’m just going to update the original posts with the new bits. I’ll add some more descriptions about why I’m doing what I’m doing, and where I got certain things.
Hopefully, this will make the series more useful.
- Sysprep and Hyper-V
- Unattended Installation of Windows and Hyper-V
- Integrated Installation and The Beauty of the Win6 Servicing Stack
In the RC0 release of Hyper-V, you may recall, you had to use the same QFE to Windows Server 2008 host and guest machines to get the Integration Component versions matching.
In RTM, you simply need to choose the Insert Integration Services Setup Disk option from the Action menu in VMConnect, just like you do for Windows XP, Windows Server 2003, and Windows Vista.
However, after you get the ICs working and you connect up to Windows Update, the Hyper-V QFE for Windows Server 2008 (KB950050) is still listed. That little logical paradox causes you to check which QFEs are actually installed on your system, and you find that KB950050 isn't in that list.
What sort of crazy voodoo magic is this?
Well, according to Occam's Razor, the simplest answer is typically the correct one.
The simplest answer in this case is that Windows isn't lying - KB950050 isn't installed. For RTM (actually, this happened in RC1), we added another QFE to the mix so that the standard way of installing the ICs (the VMGuest.ISO, which is what gets inserted into the VM's DVD-ROM drive when you click Insert Integration Services Setup Disk) worked for Windows Server 2008.
Since the RTM update actually contains an updated VMGuest.ISO file, it would be impossible for us to put the RTM update in the ISO (it's a classic "chicken-and-egg" problem).
So, we added another QFE that just contains the Integration Components and nothing else to make life easier for all of you. You can still apply KB950050 if you want to. In fact, you can just apply KB950050 if that's your thing. Or, if you want to be totally up to date, you can apply both of them.
Ok, now I'm really going to the ship party. Honest.
I arrived on this team a little over three years ago, and was brought in to work on automating test cases for Virtual Server.
While I was doing that, I heard rumblings and rumors about a little project code-named "Viridian". A lot of the developers on the Virtualization team here in Redmond had already started working on various parts of the project, and I was looking forward to the day that I could start playing with it myself. Over time, more of the team was gradually migrated to the "Viridian" project, including myself. It was exciting to hear about all of the things that we were planning to do. And over the years, the excitement never stopped.
I can still remember the day that we finally got DOS to boot (that was the first OS that Hyper-V ever booted, aside from a test microkernel that we'd developed).
I can still remember the day that Windows actually booted.
I can still remember the day that Windows x64 actually booted and joined the domain.
And I can still remember the day that setup - (well, the first incarnation of setup - you have no idea how many there have been) - actually worked, and produced a system that could boot VMs without me having to go in and change some registry keys.
Today, in our daily shiproom meeting, we signed off on the RTM build of Windows Server 2008 Hyper-V. The RTM bits should be available around noon PST (which was about 45 minutes ago...) on the Microsoft Download Center, and will be available on Windows Update on July 8th.
Instead of posting links, I'll like to John Howard's blog, since he's got some tremendous information there about where to get the RTM bits, and some things to keep in mind while upgrading.
I'll be back next week with some updates to my "Hyper-V Installation Tricks" posts for RTM, and I'll even include videos of each of the steps.
And with that, I'm going to go to the ship party.
In my last post, I said I’d be posting last week. Sorry for the late appearance of this post, but I was pre-occupied with some other tasks.
Anyway, Sean over at The Sean Blog has posted an article about getting Fedora 9 working in Virtual PC, so I thought I'd post one about installing it in Hyper-V.
So, for those of you playing along at home, here are the exceedingly complicated instructions. I hope they're easy to understand.
- Create a VM.
- Open the Settings for that VM. Add a Legacy Network Adapter, and mount the Fedora 9 ISO in the VM's DVD drive. Apply the changes.
- Start the VM and install Fedora 9. The default settings should work, unless you're advanced...
- There is no step 4.
No, seriously. It's that easy. I installed the x86-64 version under Hyper-V RC1 the other day, and it was just that simple.
Mike Sterling just made a triumphant return to blogging by posting an article on how to add the RC1 ICs to WinPE. Check it out here. Keep in mind, though, that this only works for WinPE 2.0, which is the WinPE that is based on Windows Vista and Windows Server 2008.
As for my triumphant return to blogging, I'll be back next week with some updates to old posts and new posts as well. In the mean time, I'm going to go back to playing GTA4.
Updated for Hyper-V RTM
Thus far we covered the steps necessary to capture a system image with Hyper-V installed, and how to install Windows and Hyper-V at the same time without dealing with system images at all.
Let's take a step back and talk about system images again. Images are a great way to deploy a customized version of Windows to many different workstations or servers without having to go through the effort of configuring each system independently of each other.
Even if you're just setting Windows Vista or Windows Server 2008 up from a DVD, you're still using an image to do the installation. If you look on the DVD in the \sources folder, you'll find a file called install.wim. WIM stands for Windows IMage, and it's an actual image of a real Windows installation that Setup applies directly to your hard drive (and then manipulates a bit, but that's a different story).
You can also make your own WIM files using the imagex.exe tool that ships with the Windows AIK, which I'll link to again.
The cool thing about WIMs (and there are actually many, but I'm just going to stick with the one that's relevant to this post) is that - using imagex.exe - you can mount a WIM as a folder on your Win6 (that's Vista and Server 2008)-based system and copy files to or from it, then save your changes.
So what does this have to do with Hyper-V installation?
Well, hang on... there's more that we need to talk about.
With Windows Vista and Windows Server 2008, some really cool work was done to make the operating systems more servicable. I'm not really in a position to go into all the details, but one of the absolute coolest side effects was the ability to service a Windows installation without actually booting it, which is called Offline Servicing.
No, really... what does this have to do with Hyper-V installation?
Hyper-V RTM ships as a hotfix, which means that you can use the Offline Servicing features of the servicing stack to integrate it with any Windows Server 2008 image that you've got. (This includes the retail media, as well as any image that you made yourself. For best results, you should only use images that have been sysprep'd, or are otherwise generalized.)
Assuming you're using WIMs, here's how to do it.
(Robert Larson has posted a great step-by-step article that even has pictures, if that’s more your thing. Check it out over here.)
- Download the Hyper-V RTM hotfix (it could actually be any hotfix packaged into an MSU)
- Copy the WIM file you want to integrate this fix into to a place where you have read/write access. I usually create a folder in the root of the drive called C:\image. If you’re copying files from a DVD, remember to remove the Read-Only attribute from the WIM file, either by right-clicking on it in Explorer, choosing Properties, and un-ticking the Read Only box, or issuing the command attrib c:\image\install.wim –r.
- Extract the CAB file from the MSU you just downloaded, just like we talked about in Part 2. There's also a KB article that describes the process.
- Open an elevated AIK Tools Command Prompt (because you've installed the AIK, right?).
- Create a folder to use as a mount point for your WIM (I typically use C:\mnt).
- Did you know that WIM files can contain more than one image? In fact, the INSTALL.WIM file on standard Windows Server 2008 media contains six different images! You can see all of the images in a WIM file by running imagex /info c:\image\install.wim. For starters, let’s work on image number 1.
- Run:
imagex /mountrw C:\image\install.wim 1 C:\mnt
- Run:
start /w pkgmgr /ip /m:c:\extract\Windows6.0-KB950050-x64.cab /o:c:\mnt;c:\mnt\windows /s:%temp%
- Check the return code by running:
echo %errorlevel%
If it's anything but 0, there was a failure while applying the update.
- Run:
imagex /unmount /commit c:\mnt
- If you have multiple images in your WIM that you want to patch, repeat this process – starting at step 7, and changing the “1” to whatever image number you want to patch – for each image in the WIM.
And there you have it. The next time you apply that image, your Windows installation will have the Hyper-V RTM bits already present in the package store. That's different than having the role enabled, though. You'll still need to enable it (which can be automated using parts of the unattend fragments provided in Part 2), but when you do, you'll have RTM from the beginning).
Updated for Hyper-V RTM
Picture it: Sicily, 1914. You've got a bunch of Servers that you need to install and configure Windows Server 2008 and Hyper-V on. You don't feel like messing around with Sysprep. What do you do?
Well, since none of these things existed in 1914, you're probably pretty safe, but that doesn't really help anyone right now, does it?
What you need, is a way to do an unattended installation of Windows and Hyper-V so you don't have to sit there the whole time and type commands when the system is ready for you. Lucky for you, we've already thought of that.
Before you begin, I strongly recommend that you download the Windows AIK for Windows Server 2008 and Windows Vista SP1. The AIK contains tools and documentation specifically for helping administrators just like you to roll-out Windows on a large scale. With the AIK, you'll get a nifty little tool that will help you build unattended installation files (formerly called sysprep.inf, now called unattend.xml). You can download it here.
Assumptions
- For the purposes of this post, I'm going to assume that you already have an unattend.xml file you plan on using to answer questions at install-time. In the body of this post, I'll only be providing XML fragments for you to drop into your answer file as necessary. But, just to make sure that everyone gets the information they way, I'll attach a complete and working answer file (except for the product key, of course), which you can find at the bottom of this post. (Use that file at your own risk - it repartitions your hard drive, so don't use it unless you understand everything it does!)
- You're dealing with enabling the Hyper-V role on x64 servers, and you want to apply the RTM patch.
- You're going to be using a USB key with your Windows installation media to do the unattended installation. You could just as easily create a custom install DVD with the unattend file and the RTM QFE on it. It's up to you, but I'm just going to stick with the steps for a USB key.
The Steps
- Download the Hyper-V RTM patch. (We're assuming you're doing this on the server, so we're working with x64 packages only.) It's over on the Microsoft Download Center, which is right over here. Download the MSU, and save it to your local machine.
- Create a working directory on your local machine. I prefer to call mine C:\extract.
- From an elevated command prompt, run the following command:
expand -F:* Windows6.0-KB950050-x64.msu C:\extract
- Look in C:\extract and you’ll see an assortment of files. There are only two files that you need to care about. First, take a look at Windows6.0-KB950050-x64.xml in your favorite text editor.
Look at the <package /> element. We’re going to use this in a minute, so you may want to copy it to your clipboard.
- The next file to find is Windows6.0-KB950050-x64.cab. This file contains the actual hotfix. Copy it to the root of your USB key.
- Open up your unattend.xml file and add one of the following fragments right after the <unattend /> element, but before any of the <settings /> elements.
You’ll notice that in the fragments below, we’ve used the <package /> section that we copied out of the XML file in step 4. The only change we made was to the <source /> element’s location attribute, so we can make sure that Windows Setup will know where to find the hotfix.
<!-- fragment for Server Full -->
<servicing>
<package
action="configure">
<assemblyIdentity
name="Microsoft-Windows-Foundation-Package"
version="6.0.6001.18000"
processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35"
language="" />
<selection
name="Microsoft-Hyper-V"
state="true" />
<selection
name="Microsoft-Hyper-V-Management-Clients"
state="true" />
</package>
<package
action="install">
<assemblyIdentity
name="Package_for_KB950050"
version="6.0.1.9"
processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35"
language="neutral" />
<source
location="E:\Windows6.0-KB949219-x64.cab" />
</package>
</servicing>
-or-
<!-- fragment for Server Core -->
<servicing>
<package
action="configure">
<assemblyIdentity
name="Microsoft-Windows-ServerCore-Package"
version="6.0.6001.18000"
processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35"
language="" />
<selection
name="Microsoft-Hyper-V"
state="true" />
</package>
<package
action="install">
<assemblyIdentity
name="Package_for_KB950050"
version="6.0.1.9"
processorArchitecture="amd64"
publicKeyToken="31bf3856ad364e35"
language="neutral" />
<source
location="E:\Windows6.0-KB949219-x64.cab" />
</package>
</servicing>
- Save the unattend.xml file to your USB key as "autounattend.xml".
- Go test it out. Pop a Windows installation DVD into one of your servers and plug in the USB Key that you copied all of your unattend files to. If you had the unattend file answer all of the questions during setup, the installation should just start without you having to do anything.
- Once you're at the desktop of your new Windows installation, go check in the Programs applet in the Control Panel. If you look at installed updates, you should see KB950050- the Hyper-V RTM QFE.
Updated for Hyper-V RTM
Before we jump right into this, I thought it would be best if we got a few things straight. For the remainder of this post, everytime I say "sysprep," I'm referring to running Sysprep with the /generalize switch. This is the best way to make sure that the Windows installation image that you capture and apply to other systems actually works when you put it on those other systems.
For more details on what Sysprep with and without the /generalize switch does, I encourage you to read the documentation, which I have conveniently provided a hyperlink to.
So, you're planning to sysprep a Windows Server 2008 box with Hyper-V installed? Good choice. I'm sure you'll be happy with the result, but there are few things that you'll have to do to make sure Hyper-V functions properly after you apply the image to a different computer.
The purpose of sysprep is to make the system as generic as possible so that any image taken of a sysprep'd system can then be applied to different hardware. Syspreping the system will destroy any super-specific information - like hardware IDs. The next time that Windows installation boots up, all of the information is regenerated.
With Hyper-V, however, you'll need to do a little bit of work after the system boots back up for the first time.
First, the hypervisor will not be running, since the BCD (Boot Configuration Data) store has been generalized. You'll need to run the following command to put the hypervisor launch directive back in the BCD store:
bcdedit /set hypervisorlaunchtype auto
Secondly, any virtual network switch that was set for external connectivity will revert to an internal-only switch. This is because the physical NIC that the external switch was bound to doesn't technically exist after a sysprep. You'll need to rebind the switch to a physical NIC if you want external connectivity again.
Thirdly, any disks that you have set to pass-thru (whether hard disks or CD/DVD ROM drives) will need to be set up again (this is also because of the hardware IDs).
If you have to do this on a lot of systems, I recommend that you take a look at our WMI API documentation and figure out how to do this programmatically, and then add commands to your unattend.xml file that run those scripts after the first boot on the new hardware.
I'll talk more about this in a future post.
Updated for Hyper-V RTM
As you may have heard, we've shipped Hyper-V. Sorry for the lack of posts - it seems like I'm always on vacation when we ship a major release like this, so my posts lag a few days behind.
Installing Hyper-V isn't exactly a difficult task, but if you have to do it on multiple machines, installing Windows, installing Hyper-V and then applying the RTM patch can be a bit time consuming. The purpose of this series of posts is to offer a few different ways to help you speed up your Hyper-V deployments.
Here are the major topics I'm planning to post about:
If you've got any other suggestions for topics, please let me know.
In an earlier post, I said that you should install Windows Server 2008 RC1 with Hyper-V Beta if you're getting error 61658 while trying to install the Integration Components in Windows Server 2003.
And you should.
But some people are still seeing it. If you happen to be one of them, here's why:
You probably didn't really install Windows Server 2008 RC1 with Hyper-V Beta; you probably installed Windows Server 2008 RC1, which contained the Hyper-V CTP.
I won't go into the reason behind having two similarly named releases so close together because I wasn't involved in that discussion, so any attempt to explain it would be pure speculation on my part. Needless to say, the situation we find ourselves in is that there is a Windows Server 2008 that has our beta bits in it, and one that has our old CTP bits.
If you've yet to install any build of RC1, you can get a link to download the one that has Hyper-V Beta here.
If you've already installed it and you're curious as to whether or not you've got the CTP or the Beta bits of Hyper-V, you can easily tell. If you had to double-click on any MSU files to get the role to show up in Server Manager, you have the CTP release.
After Blogging Mint:
I don't know if anyone else out there ever saw these videos, but when I was in High School, my physics class had to watch some lectures given by a man named Paul G. Hewitt. While describing miscellaneous laws of physics, he would commonly prove the law via some demonstration, then ask his class "HC?" which stood for "How come?"
My "Here's why" series of posts wasn't exactly inspired by Professor Hewitt, but I've yet to write a post without thinking about those videos in some way, so I consider them to be a sort of tip of the hat.
I feel so dirty for having chosen that as a title for this post. I mean, seriously. Out of all the blog posts that have ever been made about one changing the name of their blog, how many of them paraphrased The Bard in the title? I'm guessing "lots." Anyway, onto the actual content.
I started this blog back in 2005 with the intention of helping our valuable customers (that's you guys) use Virtual PC and Virtual Server run some brand-spankin' new operating system called Vista. Over the course of the CTP and beta releases, I made a few posts about how to get the VM Additions running under various builds of Vista and Longhorn Server.
The problem with that, though, was that eventually there wasn't anything new to write about. We released Windows Vista, and new versions of Virtual PC and Virtual Server - and everything became static. There was no new news.
Then along came Jones Hyper-V. I'm going to be blogging about Hyper-V from now on, which means that this blog is going to need a new name.
From now on, this blog shall be known as "Virtual Varia", since I think it better describes the sort of content I'll be providing here.
The URL won't change, and all of my old posts will remain just where they are.
Thanks for reading, everyone!
To continue my "here's why" series of posts, I figured I'd talk about something else that a lot of our users have run into - the infamous disappearing mouse when you try to use a Hyper-V guest while TS'd (that's Terminal Services - or Remote Desktop) into the host machine.
Here's the scenario: You've got a VM that you need to use, so you TS into your host machine, start up the Hyper-V Management Tool, connect to your VM and try to use it. Suddenly, your mouse doesn't work anymore, so you try to release it using the CTRL-ALT-Left Arrow hotkey. That doesn't work. Now you can't even use the mouse on your host operating system.
If you close your TS session and restart it, you get your mouse back, but this happens each time you try to control your guest.
Some of you are probably saying "Yes - that happens to me all the time, and it's annoying!" Others may think I'm making it up, since they've never had this problem.
So, here's what's going on. There are two modes of mouse operation when we're dealing with Virtual Machines: integrated and relative, as discussed by Ben Armstrong here.
When you TS into the host machine, your mouse is running in integrated mode. When you're using a VMConnect window to control a VM, the mouse runs in relative mode (with one important caveat, which I will come to later on). When you mix integrated and relative mode, you get badness.
So what is a humble system administrator or virtualization enthusiast to do?
There are a few work-arounds:
- Run Windows Server 2008 as a guest. No, seriously. The Hyper-V Integration Components are built into Windows Server 2008, so it will simply work in this configuration out of the box.
- Install the Integration Components for your guest operating system. This is the caveat I was talking about earlier, and is the primary reason why some of you have quite possibly never seen this. If you have the ICs installed and running, the mouse is running in integrated mode, and works flawlessly over TS.
- TS directly into the guest operating system. If there are no ICs available for your chosen guest OS, you can use TS (or any other remote control application, really) to control the guest directly. This assumes, of course, that the VM is exposed to the same network as the machine you're controlling it from.
- Use the actual, physical console of the host machine. If you take TS out of the picture, you won't have this problem.
- Remote Administration tools for Hyper-V. These aren't available yet, but in our final release, we'll provide a way for you to install the Hyper-V Manager tools on Windows Vista, so you won't actually have to run them on a server.
I've seen a lot of users having issues with installing the Hyper-V Integration Components on Windows Server 2003 in the last few days. The error code seems to differ slightly, but it's usually similar to the message below:
If you're seeing this error message, it's because you're still using the Hyper-V CTP release, and the certificate that was used to digitally sign the driver catalogs for the CTP Integration Components expired back in November.
The solution isn't very elegant - you have to install Windows Server 2008 RC1 with Hyper-V Beta.
It's also important to note that it is not supported to move VMs created with the CTP release of Hyper-V to the beta. The VHD file format is the same (in fact, it's the same as it was in Virtual Server and Virtual PC), but the VM configuration and the ICs won't work in an upgrade situation. You can try uninstalling the ICs before moving the VHDs over to Hyper-V beta, but there are no guarantees that it will work.
Along those same lines, it's not supported to upgrade to Windows Server 2008 RC1 if you have the Hyper-V CTP installed - setup will actually block the upgrade, so you'll need to clean install.
And seriously, the Hyper-V beta is amazing. If you liked the CTP, you'll really like what we've done in the beta.
I've been watching the comments - both internally and externally - about yesterday's launch of the Hyper-V Beta (yes, I know I'm on vacation, but this is exciting to watch), and I thought I'd list the answers to a few commonly asked questions.
- Q: How do I install Hyper-V on my 32-bit server?
A: You don't. Hyper-V is 64-bit only, and requires that you have an Intel or AMD processor with Virtualization extensions (Intel calls their's VT, AMD calls their's AMD-V).
- Q: How do I manage Hyper-V remotely?
A: It's not terribly easy to do with the beta. If you're running Windows Server 2008 with Hyper-V Beta on another machine besides your Hyper-V server, you can use the MMC Management Console to connect to your Hyper-V server remotely (which, in fact, you *must* do if your server is running Server Core).
If you've only got one server, you can use Terminal Services to connect to your Hyper-V server and run the MMC Management Console - though, you'll run into issues controlling the Virtual Machines with VMConnect if you don't have the Integration Components installed.
You can also use WMI calls to manage a Hyper-V server remotely. The documentation for that should be online shortly, if it isn't already.
We're going to make remote management easier to do in subsequent releases, so please stay tuned.
- Q: I've been using Hyper-V Beta for quite some time, and...
A: No, you probably haven't, unless you're a TAP customer. You may very well have used the Hyper-V CTP that was released along with Windows Server 2008 RC0 and RC1, but the beta has quite a few improvements over the CTP. If you've only looked at the CTP, you really should take another look.
- Q: How do I install the Integration Components on Windows Server 2008?
A: You don't need to. The Integration Components are now *part* of Windows Server 2008. Each IC should be available to you the first time the OS boots to the desktop.
- Q: I don't have mouse integration or the Synthetic NIC in Server 2008 Setup / WinPE. What gives?
Q: I can't PXE boot my VM. What gives?
Q: I don't have a network card in my Windows XP VM. What gives?
Q: etc...
A: PXE booting requires the Legacy Network Adapter. It will not work with the Synthetic Network Adapter. Similarly, since there are no Integration Components for Windows XP with this beta, the Synthetic Network Adapter won't work. You'll need to use the Legacy adapter.
Also, the Integration Components, including the VMBus which makes all of our synthetic devices work, are not available at install-time on Windows Server 2008, or Server 2008 WinPE. You won't have mouse integration, synthetic storage, or the synthetic network adapter until setup is complete and Windows has booted for the first time.
- Q: How do I install Hyper-V on Server Core?
A: Execute these two commands:
BCDEdit /set hypervisorlaunchtype auto
start /w OCSetup Microsoft-Hyper-V
- Q: The installation documentation doesn't say anything about that BCDEdit command - which one is right?
A: We both are. Running the OCSetup command will make the same change to the BCD store that the BCDEdit command does, but it will only do it after the required reboot, which means that even after the first reboot, the Hypervisor will still not be running and you'll have to reboot a second time. Running the BCDEdit command first will make sure that the Hypervisor will be running after the first reboot.
- Q: How do I upgrade from the CTP release?
A: You don't. There have been a lot of changes, and upgrading isn't supported. Back up all of your VHD files, and record all of the settings for your VMs, then clean install Windows Server 2008 with Hyper-V and set up your VMs again.
- Q: VMMS fails to start with error code 87 - what's up with that?
A: This beta release works on en-US builds of Windows Server 2008 *only*. If it's not en-US, you'll likely run into the error code 87 issue.
Hope that helps! If you have any other questions, please leave them in the comments, and I'll get to them as soon as I can.
