Windows Images for OpenStack

This note summarizes articles from other places on Microsoft Windows images for OpenStack creation, along with some fir St Hand experience. The whole process of creating Windows $ and Windows images fully usable on OpenStack instances is described there. Prerequisite

To achieve the creation of a qcow2 Windows image for OpenStack, we need the following ISO images:

• An ISO image of the installation DVD for all OSes This we wish to use in OpenStack. These ISOs can usually is downloaded from a company's account on Microsoft website, once the appropriate contract have been Signed. For testing purpose, Windows Server Evaluation ISO can is downloaded on Microsoft website.

• The latest VirtIO drivers for Windows. These is optimized drivers to run Windows OSes with KVM virtualized hard disk controller and network devices.

Base Image Creation

The first step to build a Microsoft Windows image was to install the OS in a VM as we would has done on a bare metal Compu ter. gridcentric ' s article about Windows image creation describes this procedure in details.

The steps to follow is:

• Create an empty qcow2 image (this'll be the disk on which we'll install our OS). I typically use a 9 GB image for Windows, and a of GB for Windows (although I think it should work with a one or (GB) image). Example:

  $ qemu-img create-f qcow2 windows-server-2008-r2.qcow2 9G

• Next step is to launch Windows ' installation-A (KVM) virtual machine. The following command is a example for:

  $ KVM-     m 2048     -cdrom <WINDOWS_INSTALLER_ISO>     -drive file=windows-server-2008-r2.qcow2,if=virtio     -drive file=<virtio_drivers_iso>,index=3,media=cdrom     -net nic,model=virtio     -net user     - Nographic     -vnc:9-     k fr     -usbdevice tablet

• The following step consists in connecting to the display of the VMs launched previously through VNC, in order to manually p Ursue the installation. This can is done with the following command:

  $ xvncviewer <ip_of_hypervisor>:9

• During the installation, Windows would ask for the hard Disk controller driver. We have to select the VirtIO driver, which are located on the VirtIO CDROM (WIN7 directory for Windows, and WIN8 Direc Tory for Windows 2012).

• Once the basic Windows installation is do, we have to set the appropriate Network device driver in the Windows Devices M Anager. The Network device VirtIO driver is available in the same directory than the hard Disk controller driver specified in the Previous step.

• Since VMs is managed by RDP and we have to activate the service. This is do by navigating through the following Menu:computer (Right-lick), Properties---Remote tab, and select ing the following option:allow connections from computers running any version of Remote Desktop.

• An additional step consisting in opening the appropriate Firewall ports are required on Windows 2012:network (right-click) Inbound rules, advanced Settings, Windows Firewall, Properties. Then Enable:remote desktop-shadow, remote Desktop-user mode TCP, remote Desktop-user mode UDP.

customizing image for OpenStack

The previous steps allowed us to has Windows fully installed in a KVM virtual machine. The last steps consist in installing Cloud-init for Windows, a Windows implementation of the Linux based Cloud-init Mechan Ism. This set of scripts transforms a legacy OS image to a ready for OpenStack image. At instantiation of a VMS, Cloud-init fetches from a meta-data server, data such as SSH public key and hostname that allows The instance to become unique. Cloud-init Base is Open source, and Cloudbase provides a installer on its blog. We'll install Cloud-init by injecting the installer that we just downloaded. To the, we have to follow these steps:

• Shutdown Windows

• Mount the qcow2 image on the hypervisor filesystem, then copy the installer in Windows ' Administrator desktop, with Someth ing like:

  $ sudo qemu-nbd-c/dev/nbd2 windows-server-2008-r2.qcow2$ sudo mount/dev/nbd2p2 mnt/$ cp <INSTALLER> <ADMINISTR ator_desktop_on_windows>$ sudo umount mnt/$ sudo qemu-nbd-d/dev/nbd2

• Restart windows in KVM with the same command, the we used to install Windows in the first place:

  $ KVM-     m 2048     -cdrom <WINDOWS_INSTALLER_ISO>     -drive file=windows-server-2008-r2.qcow2,if=virtio     -drive file=<virtio_drivers_iso>,index=3,media=cdrom     -net nic,model=virtio     -net user     - Nographic     -vnc:9-     k fr     -usbdevice tablet

• Then connect again with Xvncviewer:

  $ xvncviewer <ip_of_hypervisor>:9

• This time, we had to launch the Cloudbaseinitsetup_beta.msi installer, and follow the instructions as described on CLOUDB ASE Blog. At the end of the installation, we had to check the "Run Sysprep" option, and not the "shutdown" one. Sysprep is the tool provided by Microsoft to make a VM unique (generates a unique OS ID to being used for some Microsoft serv ICES), once it ' s instantiated.

• Once the installation is do, we can clean any temporary files created and then shutdown the system. The image is ready for uploaded in OpenStack Glance:

  $ glance Add name=<openstack_image_name> is_public=true     container_format=bare Disk_format=qcow2 < < Image_filename>

Connecting to a Windows VM

The usual mechanism used in OpenStack to connect to VMs (running Linux) is SSH. A public key specified by the user launching the VM was set in the default user ' s authorized_keys file. This allows the user to connect to the VM by using the corresponding private key.

However, it's not currently possible to connect to a Windows VMs with SSH (there are some work do in this direction that I ' ve not tested yet). Cloud-init base creates Admin a user, with either:

• A password specified by the user to the command line. Note that the password must respect Windows password strength constraints (upper and lower case characters, as well as Num bers). If not it would be silently ignored. For instance:

   $ nova Boot--key-name <KEYPAIR_NAME>--image <IMAGE_ID>--flavor <FLAVOR_ID> --nic net-id=<net_id>--meta admin_pass=<admin_password> <vm_name> 

• A PASSWORD a Utomatically generated during VM instantiation, and encrypted with the SSH public key provided when launching the VM. Such password can is retrieved and decrypted with the corresponding private SSH key, by using the following command (note That the private key is used locally):

   $ nova get-password <VM_NAME_OR_ID> <ssh_private_key> 

  li>

Note to connect to a Windows VMs from Linux, prefer using xfreerdp instead of rdesktop . T He pointer is bogus when connecting to a Windows $ VM using rdesktop .