Running Windows 7 guests on OpenStack Icehouse

VDI is a great way to enable end-users to take their corporate desktop with them on any device, anywhere in the world. Implemented correctly, it is also a great money saver for enterprises. However, to make this real, you will most certainly find yourself dealing with Windows 7 guests and a healthy dose of cloud automation.

Today OpenStack is picking up pace in the VDI sphere. Companies are dotting the OpenStack ecosystem, like Virtual Bridges and Leostream, who are providing VDI brokering platforms. Some companies have also utilized in-house talent to write cloud automation for the VDI basics. Today we won’t get too deep into the roll out of VDI on OpenStack. Instead, we will focus on the first problem — getting a Windows 7 desktop on the cloud to begin with.

There are some great tools like Oz which are trying to simplify the process of getting every OS into the cloud. However, there are still some bits being worked on in the Windows space there. In light of that, the road to getting a Windows 7 cloud image created and installed is a manual and somewhat tricky chore. To alleviate the pain, I’m going to walk step-by-step through the process I use to create Windows 7 guests.

There are a few things you will need:

• A Windows 7 image
• A Windows 7 product key
• A Linux box running KVM
• The KVM Windows Drivers ISO

Once you have those together, it’s time to start the process!

Step 1. Install Windows 7 in KVM

Fire up virt-manager on your Linux server, and you should be greeted with the following friendly GUI:

It’s not quite VirtualBox, but it works! :) Click the “Create new virtual machine” button, give the new instance a name and click forward. On the next screen, select your Windows 7 ISO and set the OS properties:

Click forward and give yourself 2 GB of RAM, and a 1 CPU, per the minimum system requirements. On the next screen select 20 GBs of space, and uncheck “Allocate entire disk now”:

Click forward and review your setup. Be sure to check the customize button before hitting finish:

You should now be at a screen where you can be a little more specific in your setup. Switch the network and disk to use virtio as shown:

Now we need to add in a cdrom for the KVM Windows Drivers. To do this click “Add Hardware”, select Storage, and a cdrom with the virtio iso:

Finally, we are ready to click “Begin Installation”! Go through the usual screens, and you will eventually get to here:

Uh.. where are the drives! No worries, this is what we brought the virtio drivers along for. Click “Load drivers” and browse to E:\WIN7\AMD64:

Click “OK” and select the “Red Hat VirtIO SCSI controller”. Your 20 GB partition should now appear. Click next, and go grab some coffee while Windows does its thing.

When it finally prompts you for a user name, enter “cloud-user”. Set a password and enter your product key. Then set the time, etc. At some point you will get a desktop and find you are without Internet connectivity. Time to install more drivers! Open the windows device manager and you should see something like this:

Right click the ethernet controller and navigate to the drivers in E:\WIN7\AMD64\. It should auto-detect your device after hitting ok.

Always Trust Software From “Red Hat, Inc.”!

Repeat this process for the other two broken devices. Finally verify the system can reach the Internet. If everything looks okay, then shutdown the guest OS and open the info panel:

Remove both cdroms, and restart the Windows guest.

Step 2. Install Cloudbase-Init

When the instance comes back up, open a browser in the guest and navigate to http://www.cloudbase.it/cloud-init-for-windows-instances/ and grab the latest cloud-init for Windows and run the installer:

For now, accept the defaults and continue the install. When everything finishes don’t let the installer run sysprep. Also, before you shutdown, edit the C:\Program Files (x86)\Cloudbase Solutions\Cloudbase-Init\conf and make it look something like this:

[DEFAULT]
username=Admin
groups=Administrators
inject_user_password=true
plugins=cloudbaseinit.plugins.windows.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.windows.createuser.CreateUserPlugin,cloudbaseinit.plugins.windows.networkconfig.NetworkConfigPlugin,cloudbaseinit.plugins.windows.sshpublickeys.SetUserSSHPublicKeysPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin,cloudbaseinit.plugins.windows.userdata.UserDataPlugin
network_adapter=
config_drive_raw_hhd=true
config_drive_cdrom=true
bsdtarpath=C:Program Files (x86)Cloudbase SolutionsCloudbase-Initbinbsdtar.exe
verbose=true
logdir=C:Program Files (x86)Cloudbase SolutionsCloudbase-Initlog
logfile=cloudbase-init.log

Now disable the Windows firewall:

All the connections to this server will be controlled the security groups in OpenStack. Also, we should allow RDP access:

Now we can shutdown, by manually running sysprep again:

C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown

Step 3. Upload Image To OpenStack

Now for the easy part! Let’s convert the image to a qcow2, and push it into glance:

# qemu-img convert -c -f raw -O qcow2 /var/lib/libvirt/images/win7.img ./win7.qcow2
# glance image-create --name="Windows 7 (x86_64)" --is-public=True --container-format=bare --disk-format=qcow2 --file=./win7.qcow2

When the upload completes, log into Horizon and verify the image is available:

Then try creating a new instance — and don’t forget to set the Admin password:

It will take a bit to spin up due to the size (around 4 GB). When the task completes, head over to the instances console and verify you have Windows 7 running [Note: you may need to update the product key in the console on the first boot]:

Now you can provision a static ip and edit your OpenStack security group to add port 3389 (RDP). Now sit back, and test connecting to your instance from something fun like an iPad :)

w00t!

Now you have a fully functional Windows 7 OpenStack image! With this you can start down the road to a slick OpenStack VDI solution. The first steps on that path are using this image to make a few customized snapshots for the various user groups in your company. These could include system wide changes particular to each division, like customized software or settings. With a little automation magic, you can take these base images, along with persistent volumes tied to each user, and create a nifty “stateless” VDI environment:

In the above example, the user requests a VDI instance. A cloud automation tool communicates with OpenStack to provision a new win7 instance, and attach the user’s persistent storage. The user then accesses the desktop through RDP, VNC, or SPICE. When they are finished, they log off and the instance is destroyed. The user’s data, living in a cinder volume, will be reattached on the next session to a new fresh image. The user gets a brand new instance, and known “perfect state” every time they log in. This could be bad news for PC support :) The BYOD movement should not be underestimated either. Employees favor it, it cuts IT costs, and arguably leads to increased productivity. With cloud VDI, you can answer one of the most important risks in BYOD — maintaining control. No more lost/stolen devices, user corrupted systems, mawlware, or viruses. Just transient desktops and data. Anytime, anywhere, any device.