Virtual Varia : Hyper-V How To

How To: Install Ubuntu 9.04 in a Hyper-V VM

mikekol — Fri, 24 Apr 2009 03:17:00 GMT

The webbernetz are abuzz with news that a new version of Ubuntu has been released today. As such, I figured that I should post instructions on how to get it going under Hyper-V.

Now, I know that these steps are pretty complex, so I'll try to use as much detail as I can when writing them out.

Step 1. Download the ISO for Ubuntu.
Step 2. Create a VM and attach the ISO to it. Use a Legacy Network Adapter if you need network access.
Step 3. Turn the VM on.
Step 4. Follow the on-screen instructions.

That's it. It works right "out of the box", so to speak.

Enjoy!

More PowerShell in R2 tricks

mikekol — Thu, 12 Feb 2009 23:30:31 GMT

The other day, Ben Armstrong posted the steps for installing Windows PowerShell on Hyper-V Server 2008 R2. How awesome is that? A real, modern, powerful shell on Hyper-V Server!

It should be noted that this also works on Windows Server 2008 R2 Core SKUs, so if you’re running Hyper-V on one of those, you can also use this trick.

So why is this cool?

Well, first of all, if you install PowerShell on a Server Core SKU, you can use a new and more powerful tool for installing and configuring server roles and features.

To do this, you need to load the Server Manager module into your shell with the following command:

Import-Module ServerManager

You can get a list of the new cmdlets that this module provides by running:

Get-Module ServerManager

So, if you’re on a Windows Server SKU, you can install all of your roles or features this way. To install Hyper-V, you would use this command:

Add-WindowsFeature Hyper-V

Ok, that’s cool and all, but it’s not that spectacular. So how about being able to actually interact with Hyper-V from this shell? Even on Server Core or Hyper-V Server 2008 R2?

Check out James O’Neill’s PSHyperV project over on CodePlex. If you download this library, you can interact with Hyper-V directly from your Core console.

The first thing to remember is that you need to dot-source the HyperV.ps1 script so that all of the functions remain in memory, like so:

. .\hyperv.ps1

After you do that, you’ll get a list of all of the new functions and filters that this library provides. Just as an example, you can create and configure a VM with these commands:

$vm = New-VM -name “MyVM”
Set-VMMemory -vm $vm -memory 2GB
Set-VMCPUCount -vm $vm -CPUCount 2
# some other logic to create a hard drive, or attach an existing one.
Start-VM -vm $vm -wait

Hyper-V Installation Tricks: Updates

mikekol — Sat, 16 Aug 2008 02:04:40 GMT

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.

Adding the RC1 Integration Components to WinPE 2.0

mikekol — Fri, 30 May 2008 23:17:00 GMT

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.

Hyper-V Installation Tricks - Part 3: Integrated Installation and The Beauty of the Win6 Servicing Stack

mikekol — Fri, 28 Mar 2008 03:18:00 GMT

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).

Hyper-V Installation Tricks - Part 2: Unattended Installation of Windows and Hyper-V

mikekol — Wed, 26 Mar 2008 09:33:00 GMT

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.


<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-

<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.

Hyper-V Installation Tricks - Part 1: Sysprep and Hyper-V

mikekol — Wed, 26 Mar 2008 09:31:35 GMT

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.

Hyper-V Installation Tricks - Prologue

mikekol — Wed, 26 Mar 2008 09:28:00 GMT

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.

How do I automate "Viridian" installation on Win2k8 RC0?

mikekol — Mon, 01 Oct 2007 22:44:00 GMT

Sorry for the abrupt end to the posts last week, everyone. I was out sick. But fear not, for I am once again a healthy and strapping young man. And as such, I hereby return to blogging Virtual Goodness!

So - automating "Viridian" installation. I'm happy to provide some information on how to do this, with the caveat that you should not be rolling out this build of "Viridian" anywhere near your data center. If you're doing a massive, wide-scale deployment of "Viridian" at this stage in the development process, and you're not a member of the TAP program, you should call a therapist immediately. If, however, you're just curious about an alternate installation method, read on.

I'm assuming by automate, we're talking about doing something simple like creating a batch file specifically to run a series of tasks that will install "Viridian", so that's the level of information I'm going to provide. Feel free to adapt this however you'd like - I promise not to copyright this.

I also won't get into how to install Windows in unattended mode - there's plenty of information on how to do that online, so I won't add yet another resource.

The first step to installing "Viridian", obviously, is to get the software onto the system. To do this, we need to stage and install¹ the two MSU packages that contain the "Viridian" server and management components.

To install the management tools from the command line, run:

start /w wusa %SystemRoot%\WSV\Windows6.0-kb939854-x64.msu /quiet

To stage the "Viridian" server components from the command line, run:

start /w wusa %SystemRoot%\WSV\Windows6.0-kb939853-x64.msu /quiet

Reboot your server before moving on to the next step using your favorite reboot technique.

To install the "Viridian" server components from the command line, run:

ServerManagerCMD.exe -install WSV

This is the command line version of the Role Management Tool that I mentioned in my original post, and will perform the installation for you.

Reboot your server again.

As for configuring the network switches or creating VMs programmatically, I'm going to simply stop here and say that yes, it will be possible in future builds. We do not have scripts available publicly that do this now, and we are not publishing any documentation on our WMI interfaces until our Beta release.

Hope this helps!

¹"What's up with this crazy lingo you're throwing around here, Mike? What's the difference between staged and installed?"
I'm glad you asked, Billy. Think of the last time that you needed to install an optional component on Windows XP or Windows Server 2003. Unless you had the whole installation CD copied to a network share or the local drive (which a lot of OEMs do), you probably needed to insert your installation CD during the process so Windows could get all the files it needed.

In Windows Vista and Windows Server 2008, we changed how that works. There's a "package store" on every installation that contains the binaries for all of the optional components and features so that you don't need to provide the installation DVD at every install/uninstall of an optional component. These binaries aren't loaded into memory, and aren't even in the same location they would be if the component was installed. They're just present on the system so that optional components and feature installation is a little bit easier.

When a component is only available in the package store, and is not installed on the system, it's staged. When a component is installed on the system, it's - you guessed it - installed.