Virtualization Tips

Xen Virtualization

Free Xen Server download ISO from citrix
http://downloadns.citrix.com.edgesuite.net/akdlm/5158/XenServer-5.6.0-install-cd.iso

Xen also available as LiveCD at http://www.xen.org/download/LiveCD/livecd-xen-3.2-0.8.2-i386.iso & http://www.xen.org/download/LiveCD/livecd-xen-3.2-0.8.2-amd64.iso

Not too sure what's xen Cloud Platform cd

Xen for some reasons don't want to shutdown (poweroff). This could be due to dom0 running on the hypervisor. The system running on Dom0 not able to shutdown the hypervisor.

Hyper-V

Hyper-V comes in 2 flavors

• Microsoft Hyper-V Server 2008 R2
• part of Microsoft Windows Server 2008 R2

Standalone Hyper-V server is free to use. The Hyper-V management console has to be from Windows paid products like Windows server 2008 R2.

If you want a reasonable working system, install Microsoft Windows Server 2008 R2 and use the Hyper-V console that comes with it.

The following servers run happily on Hyper-V

1. Windows 2003 32 bit
2. Windows 2003 64 bit
3. windows 2008 32 bit
4. Windows 2008 64 bit
5. Windows SBS 2003 32 bit
6. Windows SBS 2008 64 bit

Caveats (or known limitations)

1. The mouse don't work on remote desktop to Hyper-V console (I would prefer vmware esx/esxi to over come this shortcoming)
2. Grub4Dos based boot system has trouble under Hyper-V (This is not an issue with vmware esx/esxi)

There are many demo video for installing, configuring and using Hyper-V on YouTube.

Few learning

1. Make sure VT enabled in BIOS
2. Make sure you connect to Legacy Network (non-default) http://technet.microsoft.com/en-us/library/cc770380.aspx
3. Dell PowerEdge 1950 (1U) and 2950 (2U) are known good candidates for hosting Hyper-V

vmware Remote Console

cd C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\4.0

vmware-vmrc.exe -h -u -p -M > moid > |

Virtual Machine - Software Tester's boon

Testing x86 based Servers on VM has significant advantages over testing on Physical machines (For Software Test Teams). Some of them are

1. Server consolidation
• Saves Money as we don’t need as many physical boxes
• smaller foot print in the lab (space / Power / cables / cooling)
• Server management cost is reduced as the number of physical boxes reduced
2. Keyboard / Video / Mouse comes in at no extra cost
3. Power ON/OFF from remote machine comes with no extra cost
4. CD can be managed as file instead of physical media
• No need for physical CD
• No need to burn CD
• No need to insert the CD (Physical presence)
• No Need to take out the CD (Physical presence)

VMware tips

ESX - paid server
ESXi - free version
.vmdk - Virtual Machine Disk file format
.VMX file – this file is the primary configuration file for a virtual machine.

Enabling SSH in VMware Hypervisor.
Press ALT F1 at the physical console of the system and type 'unsupported' and then the root password of the machine. From there uncomment ssh in /etc/inetd.conf and restart services with a /sbin/services.sh restart.

Moving VM's in VMware ESXi
Connect to the hypervisor that your VMDK files are on via ssh. From there you can navigate to the vmx and vmdk files you wish to migrate under the /vmfs directory. Your VM's should be under /vmfs/volumes/datastore#. Once you are in the directory you wish to migrate you can use SCP to copy the physical disk files to the other machine. With a command similar to scp * root@hostname:/vmfs/volumes/ datastore#/vm-dir. You will need to have the destination directory created ahead of time. Once the files have copied you will need the specific command VMware-cmd for the registration of the VM with the hypervisor and to power on the VM. A command similar to VMware-cmd -H hostname_of_hypervisor -s register /vmfs/volumes/datastorename/vm-dir/vm.vmx datacenter-name resource-pool. The easiest way to register VM's is through the VMware Console. VM's can be registered with the hypervisor by navigating
to the datastore on the summary tab under the main hypervisor in the GUI. Double click on the datastore to browse the files. Right click on the VMX file you wish to register and select add to inventory.
Now that our VM has been moved and registered we are ready to boot it. You can do this from the remote command line with VMware-cmd -H hostname_of_hypervisor /vmfs/volumes/datastorename/vm-dir/vm.vmx start or through the GUI.

vim-cmd

1. vim-cmd vmsvc/getallvms
2. vim-cmd vmsvc/power.getstate
3. vim-cmd vmsvc ---- returns full list

For getting delay in power on BIOS (useful in super fast machine). Add line in .vmx file

• bios.bootDelay = "5000"
• bios.forceSetupOnce = "TRUE"

The ESX Configuring tools are located @ /usr/sbin/esxcfg*

http://serverfault.com/questions/28399/how-to-run-vmware-esx-or-esxi-in-a-virtual-machine

VMWare ESX or ESXi CAN run inside a virtual machine, provided certain prerequisites are satisfied.
This kind of setup is of course completely useless (and totally unsupported) in a production environment, but can be very useful for two purposes:

• Testing or studying ESX or ESXi if you don't have a physical server available.
• Testing or studying the whole Virtual Infrastructure if you don't have at least two servers and a SAN.

---

Prerequisites:

• You need some physical resources. In order to run ESX or ESXi in VM, the VM needs at least 1.5 GB of memory, two VCPUs and enough disk space for the server itself and for the VMs you will run inside it.
• You absolutely need a physical CPU with native virtualization support (Intel VT or AMD-V).
• You need to run VMWare Workstation 6.5 or VMWare Server 2 on the physical host. Previous versions can't succesfully run ESX or ESXi in a VM.
• A 64-bit OS on the physical host is useful but not required.

Setup:

• Enable native virtualization support for your CPU in the motherboard BIOS (it's often not enabled by default).
• Install your preferred virtualization software. I've tested everything succesfully using VMWare Workstation 6.5.2 on a Windows XP x64 host, but it should work with VMWare Server 2.0 and/or Linux hosts, too.
• Create a custom VM using those setting:
  • Hardware compatibility level: latest
  • Guest operating system: other 64-bit
  • Virtual CPUs: at least 2
  • Memory: at least 1.5 GB
  • Networking: Host-only or NAT
  • SCSI adapter: LSI Logic
  • Virtual disk type: SCSI
  • Virtual disks: as you wish; I suggest using at least two virtual disks, a 10-GB one for installing the system and another one where to create a datastore. The space should be pre-allocated.
  • Remove floppy, sound card, USB controller, etc. Leave only networking and storage.
  • CPU Execution mode: Intel VT-x or AMD-V (very important).
• Manually edit the VMX file of the virtual machine you created, setting the following parameters:
  guestOS = "vmkernel"
monitor_control.vt32 = "TRUE"
monitor_control.restrict_backdoor = "TRUE"
• Start the VM and install ESX or ESXi from the installation ISO image.
• Configure the networking to allow the ESX or ESXi virtual server to talk with the host.

Usage:

• Use your web browser to connect to you virtual server's IP address and download the VI Client.
• Install the VI Client on the host.
• Connect to the virtual ESX/ESXi server.
• Create a VM as you wish.
• Power up the VM.
• If everything is done correctly, the VM will start. If it complains about not being able to power on a VM inside a VM, then there is an error with the `monitor_control.restrict_backdoor' parameter (or you're using an old version of VMWare Workstation/Server).
  VMWare Server 2.0, you won't be able to select the CPU execution mode in the GUI; you can fix this by adding the following line to the .vmx file: monitor.virtual_exec = "hardware"

WMware Player running from Physical Partition

Running a Windows Partition in VMware

I have my system partitioned into two: one part of the hard drive hosts a Windows XP partition, and the other runs Gentoo Linux. About a month ago, I was just about tired of having to reboot to switch between the two, so I decided to set up a VM for Windows.

There was, however, a snag to this: I wanted to use the existing Windows installation, because I'd tuned it up and installed the software I always use. I expressly didn't want a virtual disk image duplicating my Windows drive, since I didn't have the space for that. So, that was the task: running the Windows partition in a VM.

I hunted around the 'Net, and found surprisingly little information on this: the procedure I finally threw together was sourced from many disparate places. So, in one place, I've put together the steps you'll need to take in order to get a Windows partition running inside a VM.

What you'll need

You'll need a few tools in order to pull the information you need, and to run the finished VM:

VMware Player:

The easiest way to get a finished VM running; all you need to do is point the VM information file at vmplayer, and you're good to go.

VMware kernel modules for Linux:

All VMware products on Linux use kernel modules to get monitoring and networking functionality working, so you'll need those.

A text editor:

We'll be doing some hacking of configuration and VM information files, which means your favourite text editor.

GNU Parted:

In order for us to tell VMware about the hard disk, we need to know a few things about the disk; we'll also be doing a little hacking of the partition table. Parted allows us to do this from the command line, and quite easily too.

On a Gentoo Linux installation, you can get the software you need on the Linux side from the following command (on other distributions, check your associated documentation):

emerge vmware-player vmware-modules parted

Stage 1: Setting up a virtual hard disk

VMware needs a virtual disk descriptor file, telling it how the disk is set up and structured. So, dump the following into a file called WindowsXP.vmdk:

Disk description: WindowsXP.vmdk

# Disk DescriptorFile version=1 CID=9428f535 parentCID=ffffffff createType="fullDevice" # Extent description RW 63 FLAT "WindowsXP.mbr" 0 RW 23579072 FLAT "/dev/hda" 63 # The Disk Data Base #DDB ddb.toolsVersion = "6530" ddb.adapterType = "ide" ddb.virtualHWVersion = "4" ddb.geometry.sectors = "63" ddb.geometry.heads = "240" ddb.geometry.cylinders = "1559"

The values highlighted in red are ones you'll need to change, depending on the characteristics of your hard disk: they describe my disk quite well.

Now you can fire up Parted against the disk you want to use. If you have Windows on one hard disk and Linux on another, use the Windows disk in the command below, otherwise just use the disk device containing the Windows partition.

Fetching disk information: Parted output

# parted /dev/hda GNU Parted 1.7.1 Using /dev/hda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) unit s (parted) print Disk /dev/hda: 23579135s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 63s 9223199s 9223137s primary ntfs 2 9223200s 22679999s 13456800s primary ext3 boot 3 22680000s 23572079s 892080s primary linux-swap (parted) unit cyl (parted) print Disk /dev/hda: 1559cyl Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 1559,240,63. Each cylinder is 7741kB. Partition Table: msdos Number Start End Size Type File system Flags 1 0cyl 609cyl 609cyl primary ntfs 2 610cyl 1499cyl 890cyl primary ext3 boot 3 1500cyl 1558cyl 59cyl primary linux-swap

Note the unit s command, which tells Parted to print out its values in terms of disk sectors: we'll be using these values in the VMDK file. Also note the second unit command, to provide the values in cylinders; that allows us to fetch the disk geometry in CHS format.

The values in red are the ones we'll be using. But not so fast; before you plug the values in, we'll need to do some calculation. Instead of using the hard disk's standard boot sector, which allows you to boot Windows or Linux, we ideally want the VM to boot only Windows. We'll be doing that by telling the Windows partition to boot, ignoring the Linux boot menu, and then making a copy of that bootsector for the VM to use.

All that means we need two lines in the VMDK, as shown above: a line for the bootsector copy, starting at sector 0 and stretching for 63 sectors; and the rest of the hard disk, starting at sector 63. And that means a little calculation: the value in the VMDK for the size of the disk is 63 less than the actual disk.

Size of the virtual disk: Subtracting the MBR

23579135 - 63 = 23579072

Note that this is the value I've got in my VMDK, shown above.

I mentioned above that we'll be using a copy of the disk's bootsector for the VM, with Windows set to boot. We'll need to set that up first:

Setting Windows to boot: Parted output

(parted) set 1 boot on (parted) print Disk /dev/hda: 1559cyl Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 1559,240,63. Each cylinder is 7741kB. Partition Table: msdos Number Start End Size Type File system Flags 1 0cyl 609cyl 609cyl primary ntfs boot 2 610cyl 1499cyl 890cyl primary ext3 3 1500cyl 1558cyl 59cyl primary linux-swap (parted) quit #

Now to make a copy of the bootsector, using the infamous dd utility:

Copying the bootsector

# dd if=/dev/hda of=WindowsXP.mbr bs=512 count=63 63+0 sectors in 63+0 sectors out #

Stage 2: The VMware information file

Once the VMDK is set up, we need to tell VMware what exactly it'll be booting, and which hardware to emulate. This is done by the information file, which in this case is WindowsXP.vmx:

The information file: WindowsXP.vmx

config.version = "8" virtualHW.version = "4" uuid.location = "56 4d 56 4a 7b d7 4c 30-f5 80 d6 8b c4 59 aa eb" uuid.bios = "56 4d 56 4a 7b d7 4c 30-f5 80 d6 8b c4 59 aa eb" uuid.action = "create" checkpoint.vmState = "" displayName = "Windows XP Professional" annotation = "" guestinfo.vmware.product.long = "" guestinfo.vmware.product.url = "" guestOS = "winxppro" numvcpus = "1" memsize = "128" paevm = "FALSE" sched.mem.pshare.enable = "TRUE" MemAllowAutoScaleDown = "FALSE" MemTrimRate = "-1" nvram = "WindowsXP.nvram" mks.enable3d = "FALSE" vmmouse.present = "FALSE" vmmouse.fileName = "auto detect" tools.syncTime = "TRUE" tools.remindinstall = "FALSE" isolation.tools.hgfs.disable = "FALSE" isolation.tools.dnd.disable = "FALSE" isolation.tools.copy.enable = "TRUE" isolation.tools.paste.enabled = "TRUE" gui.restricted = "FALSE" ethernet0.present = "TRUE" ethernet0.connectionType = "nat" ethernet0.addressType = "generated" ethernet0.generatedAddress = "00:0c:29:59:aa:eb" ethernet0.generatedAddressOffset = "0" usb.present = "TRUE" usb.generic.autoconnect = "TRUE" sound.present = "TRUE" sound.virtualdev = "sb16" ide0:0.present = "TRUE" ide0:0.fileName = "WindowsXP.vmdk" ide0:0.mode = "independent-persistent" ide0:0.deviceType = "rawDisk" ide0:0.redo = "" ide0:0.writeThrough = "FALSE" ide0:0.startConnected = "TRUE" ide1:0.present = "TRUE" ide1:0.fileName = "/dev/cdrom" ide1:0.deviceType = "atapi-cdrom" ide1:0.writeThrough = "FALSE" ide1:0.startConnected = "TRUE" floppy0.present = "TRUE" floppy0.fileName = "/dev/fd0" floppy0.startConnected = "TRUE" serial0.present = "FALSE" serial1.present = "FALSE" parallel0.present = "FALSE"

I've highlighted a couple of values which you might want to change: the location of the CD drive in the device tree, and the amount of memory you want to allocate to the VM.

Stage 3: Setting up Windows

We're not done yet; the Linux side of setting up the VM is running, but we now need to tell Windows that it'll be booting into a VM. The problem is rooted in the fact that the VM's hardware is different to your physical computer; thus, we need to add a hardware profile to the Windows partition.

We can also take this opportunity to test that the Windows partition boots up immediately, without a boot menu in the way. Reboot, and if the boot process doesn't run straight to Windows, you may need to tweak the partition boot settings and recreate the bootsector copy.

Once you're booted into Windows, pull open the System properties (Control Panel -> System, or My Computer (rightclick)-> Properties):

The default setup for this Hardware Profiles display is one profile, called "Default". Click on "Copy", to create a new profile, and call that one "VMware", then move it to the top of the list with the arrow buttons. You can see the settings I use in the image above, and we'll see exactly what that means for the Windows boot process in a little while.

While you have the System Properties open, pull open the Driver Signing properties, and set the value of what action Windows should take to "Ignore"; this allows any drivers to be installed automatically if devices are picked up by Windows.

This is also a good time to set up a helper script, which will install the VMware Tools: a set of drivers for the VMware emulated devices, and some services to help the Windows VM along. This could be done after the VM is set up and running, but I had issues with that, as detailed later. I've decided to put it here in stage 3, to catch the problem before it begins.

The VMware tools are provided by VMware as a CD ISO image, buried within the VMware Workstation software. It's relatively easy to find: first of all, download Workstation from VMware, or any Linux mirror (I've given a sample mirror below):

http://ftp.snt.utwente.nl/pub/os/linux/gentoo/distfiles/VMware-workstation-5.5.3-34685.tar.gz

Once you've got the file, extract its contents (you may need third-party tools to do this in Windows), and look for a file called windows.iso; this is the Tools CD image. If you feel like wasting a CD, burn the image to one, or you can mount the image as a drive using Daemon Tools or similar software.

When you can see the contents of the image, copy the files to your hard disk, in a directory calledC:\VMTools or something similar. Then dump the following into a .cmd file:

VMware Tools install helper: C:\VMTools\ToolsHelper.cmd

if exist C:\VMTools\ToolsHelperLock.txt msiexec -i "C:\VMTools\VMware Tools.msi" /qn if exist C:\VMTools\ToolsHelperLock.txt shutdown -r -f -t 30 del C:\VMTools\ToolsHelperLock.txt

Also, put a small message (any you like) into ToolsHelperLock.txt in the same directory. The lock file will be used by the helper script to work out if it needs to reboot. Once you've done this, add the script to your Start Menu's Startup folder, and you'll be away.

Log yourself out of Windows and reboot; that should be the last time it needs to be started physically. Boot yourself into Linux; it's time to test this thing.

Stage 4: Virtual Windows

When you fire up the VM, it should now automatically pick up the Windows partition, and begin booting it. The presence of two hardware profiles means that Windows will ask which one you wish to use:

Pick the VMware profile, and Windows should boot, into a very minimal VGA-colour mode: it doesn't have the drivers for the "VMware SVGA" yet. At this point, the helper script should kick in, install the VMware tools, and then reboot the VM. Make sure to remove the helper script from your Startup folder upon the next reboot; even though it won't run, it'll still flash a Command-Prompt window up for a short while.

Snags: Getting the network running

I mentioned earlier that I had a problem with my keyboard and mouse not being detected by Windows in the VM, thus bringing about the helper script to allow the VMware tools to install the requisite drivers. I did have another issue with the VM, and that was getting it to talk to the outside world.

Initially, I set the VM's network card to a "bridged" type, allowing it to reside on the same network as the host machine; this usually works fine. In the case of a laptop with wireless, however, it didn't so much: no communication. After some experimentation, I resorted to the NAT method: one network that the host computer sits on, and another between the host and VM. This also involves a bit of iptables trickery, so I'm putting it in as a part of this guide.

In my case, the normal wireless network resides on 192.168.1.0/24, so I decided to put the virtual network at 192.168.58.0/24. This means the host gets an address of 192.168.58.1 on the NAT network, and the VM's network connection gets a static IP of 192.168.58.2; it also means the following changes to the Linux host's configuration:

Allowing IP forwarding: /etc/sysctl.conf

net.ipv4.ip_forward = 1

Initialising iptables NAT: /etc/conf.d/local.start

ifconfig ra0:1 192.168.1.252 iptables -t nat -A PREROUTING -i ra0 -d 192.168.1.252 -j DNAT --to-destination 192.168.58.2 iptables -t nat -A POSTROUTING -o ra0 -s 192.168.58.2 -j SNAT --to-source 192.168.1.252 iptables -A INPUT -i ra0 -d 192.168.1.252 -p tcp -j ACCEPT iptables -A INPUT -i ra0 -d 192.168.1.252 -p udp -j ACCEPT iptables -A INPUT -i ra0 -d 192.168.1.252 -p icmp -j ACCEPT

Note how the wireless interface ra0 has had a virtual interface added, dedicated to the transfer of traffic for the virtual machine NAT. The particular configuration files you need to change may differ depending on the distribution; the changes above are from my Gentoo system.

In the End: Windows in a VM

After all's said and done, you should have something like this:

Enjoy it!

VMware delighted me on Fusion feature

VMware Fusion can run from physical disk on Bootcamp partition. This way, one can run on Bootcamp (real hardware) for high performance needs. Run on virtual machine for some quick tasks.

Advantages:

1. No 2 Windows licenses
2. No need to keep track of changes and synch between the 2 windows installations.

We will be missing the following features that are available only as "Virtual-only" features

1. Snapshot
2. Autoprotect (?)
3. Instant suspend/resume