In this document I am presenting a solution based on SUSE Linux Enterprise Desktop 10 SP1 with VMware virtualization. The outcome is a multi-boot (Linux/Windows) environment which allows user to load both systems natively and virtualized as well providing ultimate flexibility. Because the solution uses real hard drive partitions (not file images) the performance is very attractive.
What is it exactly?
Imagine you have a multi-boot system. You load the Linux in, it becomes the host so your existing (multi-boot ready) Windows copy will run virtualized. It is also possible that you load the Windows in, it shall become the host so your Linux copy can run virtualized however this part is out of the scope of this document. Note: If you plan experimenting with this part you must have 32bit versions of both systems due to VMware 5.x is limited at this time of writing and will not be able to load your 64bit Linux in. The approach is the same though. VMware-workstation 6.0 and VMware-player 2.0 are capable of running different 64bit VM on top of 32bit host and vice versa.
SLED10-SP1 comes with built in Xen virtualization product but according to my experience VMware is more efficient for Windows desktop virtualization at this time of writing.
The solution presented here is not new in fact was worked out from various discussion forums, other documents available around the Internet. The purpose of this however is to bring all related information together and present them in one document matching corporate environment based on SLED10-SP1.
- No suspend function available for the VM, you must shut it down cleanly
- Zenworks imaging is more than likely to fail as it’s not using entire hard drive imaging AKA bit to bit copy. Alternative solutions could be: g4u (ghost for linux) or a simple dd image perhaps other commercial imaging utilities.
The solution is rather explanatory with less technical detail and based on an assumption that the audience has already gained Linux, SLED, VMware knowledge. The key of the success is the order.
- *Update: Watch out for BIOS options and newer hardware!!!We found this not to work with a new HP nc8430 laptop. After a bit of a digging we found that it has some extra options in the BIOS:
bios F.15 [2007-11-23]
“System Configurations”/”Device Configurations”/”SATA Native Mode” [default is Enabled]
The “SATA Native Mode” didn’t appear to be harmful so it’s your choice to leave it on or not but bear in mind that if you do leave it on Windows will need driver disk to be loaded at the boot process of the installation (F6).
“System Configurations”/”Device Configurations”/”HDD Translation Mode” [default is Bit-shift]
This was the guilty one. This solution doesn’t work with drives using “Bit-shift” so you have to change it to “LBA-assisted”. Some systems may have option “Automatic” but I wouldn’t trust in that.
“System Configurations”/”Device Configurations”/”Virtualization Technology” [default is Disabled]
You may want to enable this, can’t be harmful and there are some scenarios when you will need it.
- Install Windows first. It has to be a clean, fresh install on primary master, no drivers whatsoever. It must also be a “Volume License” copy. Our enterprise does have one therefore we don’t deal with product activation issues.
OEM users: the issue is that WPA is poorly designed. VMware hardware is a lot different than the native one (pretty much everything is virtualized) therefore it will need re-activation when you switch from the native Windows to the virtualized one and vice versa. The only workaround at this stage (without breaching EULA) is to backup the c:\windows\system32\wpa.bak and wpa.dbl files. If you activated the product for both profiles and of course backed up the files mentioned you can swap the WPA files upon changing profile. It’s such a hassle due to the fact that it has to be done in “safe mode” but if you desperately need the native copy (assume it’s the one least used) you can have it.
- After first login (Windows) copy the current HW profile and name it VMware or similar. Right click on “My Computer” select “Properties” then “Hardware profiles” You have to disable the timeout here to avoid loading the wrong profile in.
- Reboot it with the new VMware profile (still in native Windows) then go to “Control Panel”-> “System”->”Properties”->”Device Manager” select the Primary IDE controller and replace its driver with “Standard Dual channel PCI IDE controller” It is the most common for users with SATA drives. The issue is that VMware (due to Linux considers SATA as SCSI) will see it as SCSI but Windows as IDE. So we need to prepare the HW profile for the virtualized environment. If your native Linux and native Windows identifies your drive with identical interfaces (IDE-IDE, SCSI-SCSI) then there should nothing to be done.
- Once you have the the VMware HW profile prepared, you can proceed with Windows install for the original HW profile. Use always the right HW profile, install your drivers, softwares as you do usually.
- Install SLED10-SP1 on top, GRUB should find and treat the system accordingly (multi-boot) Things to watch out for:
- It’s wise to have (at this stage) the same architecture for Windows and Linux, do not mix them. 32 bit Windows goes with 32 bit Linux. I chose that to avoid application issues by the way the performance loss is very minimal.
- DO NOT not make the partitioning too complex. LVM or software RAID may not be possible with this setup. I used common UNIX partition schema.
- you cannot have VMware and Xen at the same time, DO NOT select Xen at the Software section
- do select C/C++ compiler and tools at the Software section
- the boot configuration is usually perfect, do not change anything there if unsure
- When finished and successfully logged in we install VMware-workstation-5.5.4-44386.rpm package first to create the config file. It’s available for 30 day evaluation and needs no licensing to create the config file. I installed it, created a config file then removed it and replaced with Vmware-Player-1.0.4-44386.rpm package. Both work the same way, out of the box. There is no need for “vmware-any-any” patching anymore:
geeko:~ # uname -a Linux geeko 184.108.40.206-0.12-smp #1 SMP Thu May 17 14:00:09 UTC 2007 i686 athlon i386 GNU/Linux geeko:~ # rpm -ivh VMware-workstation-5.5.4-44386.i386.rpm Preparing... ########################################### [100%] 1:VMwareWorkstation ########################################### [100%]
Configure the software, it will ask some questions, accept the defaults if unsure. At completion it will compile the required modules then start VMware service:
geeko:~ # vmware-config.pl
Create the VM config file. I present only the important stages here, for the rest accept the defaults.
geeko:~ > vmware &
VMware Player can make use of only 1 core at this stage:
Don’t push the memory over the recommended limit! The VM runs as single process and will consume the amount of memory you allocate here. You shouldn’t risk your host allocating too much for the VM (single process). I have 1 GB altogether and use half of it for the VM.
Accept default I/O adapter:
Select physical disk:
Even if it looks odd, you must select entire disk:
Notes: If your primary network connection on the host is Wireless select NAT instead bridging. It’s a limitation of the Linux wireless at this stage. You will need to re-edit your config and select your configured NAT networking (NAT is vmnet8 as default) explicitly if you cannot get the virtualized networking working. For wired connection the default bridging works out of the box.
- In default the “disk” group has no write access to any block devices. In SuSE the /dev directory is tmpfs meaning that it gets re-created every time the system boots therefore this has to be solved by udev. We change the default permission for block devices to 660:
geeko: ~ # vi /etc/udev/rules.d/50-udev-default.rules -snip- # block devices SUBSYSTEM=="block", GROUP="disk", MODE="0660" -snip-
To avoid rebooting (test it after reboot too):
geeko: ~ # chmod g+w /dev/sda*
Once you finished you have to add your user to the “disk” group for being able to write to the raw device:
geeko:~ # usermod geeko -G disk
- Disable the timeout (counter) in GRUB! You don’t want to load your host system in a VM environment accidentally:
geeko: ~ # vi /boot/grub/menu.lst | grep timeout #timeout=3
- Change the config files of yours with your preferred editor. Things to be changed: the “scsi0.present” must be “FALSE”. All the rest of “scsi” bits must be replaced with “ide” I presented my config file after the related changes:
geeko: ~ > vi /home/geeko/vmware/Windows\ XP\ Professional/Windows\ XP\ Professional.vmx -snip- scsi0.present = "FALSE" ide0:0.present = "TRUE" ide0:0.fileName = "Windows XP Professional.vmdk" ide0:0.writeThrough = "FALSE" ide0:0.deviceType = "rawDisk" -snip-
You must also ensure that VMware sees your right disk geometry. It’s usually fine but at some special drives it needs adjustment. Only the “ddb.adapterType = “ide” line needs changing from “scsi” to “ide” It is my config after the change:
geeko: ~ > vi /home/geeko/vmware/Windows\ XP\ Professional/Windows\ XP\ Professional.vmdk -snip- ddb.virtualHWVersion = "4" ddb.geometry.cylinders = "9729" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.geometry.biosCylinders = "9729" ddb.geometry.biosHeads = "255" ddb.geometry.biosSectors = "63" ddb.adapterType = "ide" ddb.toolsVersion = "6435" -snip-
To double check the disk details:
geeko:~ # hdparm -g /dev/sda /dev/sda: geometry = 9729/255/63, sectors = 156301488, start = 0
You could also force grub to see the right disk geometry (very very rarely needed) by adding the following option to the “kernel” line of your grub config: “sda=9729,255,63” Do not do this unless you have good reason so!
geeko:~ > grep kernel /boot/grub/menu.lst kernel /boot/vmlinuz-220.127.116.11-0.12-smp root=/dev/disk/by-id/scsi -SATA_ST380815AS_5RW0H5HR-part6 vga=0x31a resume=/dev/sda5 splash=silent showopts sda=9729/255/63
- Ensure that your Windows partition is NOT mounted in Linux. Most systems do it now automatically. You need to unmount it to avoid file system corruption or other issues even though it would be read only due to the nature of the NTFS support in Linux.
geeko:~ # umount /windows/C geeko:~ # grep -i windows /etc/fstab /dev/disk/by-id/scsi-SATA_ST380815AS_5RW0H5HR-part1 /windows/C ntfs ro,noauto,users,gid=users,umask=0002,nls=utf8 0 0
We can add noauto option to fstab causing the system not mounting it at next reboot. Do not get confused, it will still appear on your desktop but will not be mounted. Bear in mind as soon as you click on it it will be! Better yet to comment it out entirely:
geeko:~ # grep -i windows /etc/fstab #/dev/disk/by-id/scsi-SATA_ST380815AS_5RW0H5HR-part1 /windows/C ntfs ro,noauto,users,gid=users,umask=0002,nls=utf8 0 0
- From now on we wouldn’t need the VMware-workstation package therefore I will uninstall it and replace it with VMware-player package. It should not affect your existing configuration as it’s kept in your home directory.Before that we create a copy of the VMware-tools directory. It’s important for the virtualized systems and not included in the VMware-player package:
geeko:~ > cp -a /usr/lib/vmware/isoimages ~
Proceed with the uninstall:
geeko:~ # rpm -qa | grep -i vmware VMwareWorkstation-5.5.4-44386 geeko:~ # rpm -e VmwareWorkstation-5.5.4-44386
geeko:~ # rpm -ivh VMware-player-1.0.4-44386.i386.rpm Preparing... ########################################### [100%] 1:VMwarePlayer ########################################### [100%] geeko:~ # vmware-config.pl
Proceed as before then finish.
- Fix some library incompatibilities. It needs to be done if VMware player hangs/freezes when you try running it. It’s very common and I think all systems need it but try it out first to see if you are affected. If so:
geeko:~ # cd /usr/lib/vmware/lib/libpng12.so.0/ geeko:~ # mv libpng12.so.0 libpng12.so.0.old geeko:~ # ln -sf /usr/lib/libpng12.so.0 libpng12.so.0 geeko:~ # cd /usr/lib/vmware/lib/libgcc_s.so.1 geeko:~ # mv libgcc_s.so.1 libgcc_s.so.1.old geeko:~ # ln -sf /lib/libgcc_s.so.1
The original knowledge base entry:
- Now start the VM with VMware Player, should start up fine. At the virtualized Grub screen select your Windows partition then the VMware HW profile. If you end up having a blue screen means the disk driver is not right in your VMware profile:
We need to install the VMware-tools package which improves the performance of when Windows is virtualized. It can’t be done on the native copy! Shut the VM down first then make the following change to your configuration file:
geeko: ~ > vi /home/geeko/vmware/Windows\ XP\ Professional/Windows\ XP\ Professional.vmx -snip- ide1:0.fileName = "/dev/sr0" ide1:0.deviceType = "cdrom-raw" -snip-
Replace these two lines with the following reflecting your location to the iso images we made a copy of a while ago:
ide1:0.fileName = "/home/geeko/isoimages/windows.iso" ide1:0.deviceType = "cdrom-image"
Fire the VM up. You can now install the VMware-tools, your CD drive will be the mounted iso image:
Shut the VM down when finished then and swap back the entries as we will not need the iso to be mounted any longer:
geeko: ~ # vi /home/geeko/vmware/Windows\ XP\ Professional/Windows\ XP\ Professional.vmx -snip- ide1:0.fileName = "/dev/sr0" ide1:0.deviceType = "cdrom-raw" -snip-
- You may want to disable devices in the VMware hardware profile what do not exist in the virtual environment (what you have in the native one) and vice versa:Go to the device manager then select “View”->”Show Hidden Devices”. Select every device that are not present in the VM (for instance your native LAN cards) followed by right click-> “Properties”->”Device Usage”->”Do not use this device in the current hardware profile” I got serious delays at login due to the system tried to bring up my native wireless and wired connections.
For users who plan to make an image of this setup will probably need to move the VMware configuration to a common location for instance /VMware. Files under this directory should be owned by the root user and certain users should only be able to write to that area. It can nicely be done with extended ACLs. Later on you just need to drop a shortcut to the users desktop pointing to the custom location.
When you upgrade the kernel you will have to re-run “vmware-config.pl” and recompile the modules for the new kernel.
Section 9. may need to be done again when affected packages get updated for instance libpng.