Concerning this topic I was asked if it’s possible to have the BootCamp partition only umounted upon startup of the Windows VM.

My original post referred to creating the file /etc/rc.local (or just editing it, if it already existed) and adding these commands in there:


# grant VirtualBox permissions to Boot Camp partition
#
sudo chmod 777 /dev/disk0s3
diskutil umount /Volumes/BOOTCAMP


The method described basically causes the system to grant permissions for raw partition access and permanently umount the BootCamp partition during bootup.
If you however want the BootCamp partition only umounted upon startup of the Windows VM then please proceed as outlined below.

First of all, edit your /etc/rc.local to just include these lines:


# grant VirtualBox permissions to Boot Camp partition
#
sudo chmod 777 /dev/disk0s3


This will cause the permission to be properly set upon boot of OS X, which is still required. The partition however will not be umounted and thus appear on your Finder as usual.

Now, assuming that you implemented the application shortcut method, you need to change the application launcher like this from your Terminal:


cd "VirtualBox VMs/Win7onMBP"

cat > "Windows 7.app/Contents/MacOS/startvm" << EOF
#!/bin/sh
diskutil umount /Volumes/BOOTCAMP
[ ! -d /Volumes/Bootcamp ] && /usr/bin/VBoxManage startvm Win7onMBP
EOF


This will try to umount the BootCamp partition automatically when you click the icon.
However, I’ve added an additional safety switch in there: I’m checking if the BootCamp partition is still mounted at /Volumes/BOOTCAMP. VirtualBox will only start if the BootCamp partition is not mounted. This will help in preventing ugly issues with partition access.

Luckily VirtualBox provides us with everything needed to accomplish this through the “VBoxManage” command.
The rest is just some (not so really) magic OS X trickery, as you’ll find out shortly.

Download the Icon

You’ll most likely want to have a decent icon for your application shortcut.
Since OS X can’t work with standard Windows .ico files, you’ll need a special OS X icon (.icns format).
As a convenience I provide you with my own here. Just download to your “Downloads” folder. You will need to extract it first before you continue.

If you want to make your icon, here’s a short howto on this topic.

Create the Application

This task is entirely done from OS X Terminal, so let’s start a new Terminal.

If your Mac is set with defaults, your startup directory will be your home directory, which should evaluate to /Users/USERNAME.
Mine is /Users/Gianpaolo for example. You can always check your current working directory using the ‘pwd’ command.

I keep all my VMs under my home directory in a folder called “VirtualBox VMs”, where each VM again has its own directory.
My Windows VM is called “Win7onMBP”, so I need to change to it’s directory first:


cd "VirtualBox VMs/Win7onMBP"


As said earlier, the “VBoxManage” command will be used to launch the VM. As a convenience I create a real OS X application shortcut, which can be used like every other application, e.g. dragged onto the OS X dock. This offers a maximum of integration into the Finder as possible. Though it may seem a bit more complicated to setup, you’re actually better of with this method than with tradional aliases.

Just paste these lines below directly into your Terminal to create the application and all of it’s dependencies.
For it work properly, please make sure you downloaded my icon file to your Downloads folder as “win7.icns”.


mkdir -p "Windows 7.app"
mkdir -p "Windows 7.app/Contents"
mkdir -p "Windows 7.app/Contents/MacOS"
mkdir -p "Windows 7.app/Contents/Resources"

cp ~/Downloads/win7.icns "Windows 7.app/Contents/Resources"

cat > "Windows 7.app/Contents/Info.plist" << EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>startvm</string>
<key>CFBundleIconFile</key>
<string>win7.icns</string>
</dict>
</plist>
EOF


Here’s a screenshot of my Terminal transcript:

Add the Application to the Dock

As said before, I want the application icon in my dock. So here’s how to do it. For this you won’t need Terminal anymore, so you can safely close it now. Instead you’ll need to fire up Finder and navigate to your VM directory. Find the “Windows 7″ app created earlier and select it.
Then simply drag it onto the OS X dock.

Voilà, you’re done.

Luckily, it’s only a (hopefully short-lived) compatility issue. While this will surely need a final fix, here’s a temporary workaround…

Apple decided to boot the x86_64 64-bit kernel by default on Mac Pro (mid 2010) and MacBook Pro (early 2011).

Unfortunately there seems to be an issue between VirtualBox and OS X using the 64-bit kernel on the new Sandy-Bridge Systems, which causes poor VirtualBox performance.

If you suspect this to be the case, run “System Profiler”, which you find either through Spotlight or in Apple-Menu -> About this Mac -> More Information. Click the “Software” item and check for the “64-bit Kernel and Extensions”. If it reads “Yes”, you’re running the 64-bit kernel and are likely to be affected by this issue.

To fix the issue for now, set OS X to boot using the 32-bit kernel.
Open a “Terminal” and run this command to do so:


sudo systemsetup -setkernelbootarchitecture i386


If you decide to use the 64-bit kernel at a later point, just revert it using this command:


sudo systemsetup -setkernelbootarchitecture x86_64


Let’s hope, that this issue will get a proper fix soon. Until then, most of will live good enough using the 32-bit kernel, as it will also run perfectly using native 64-bit apps. It shall be noted though, that some apps, e.g. for graphics processing, may suffer a slightly degraded performance using the 32-bit kernel. Personally I’m not using such applications, so it’s fine for me. After all, my VirtualBox VMs run full speed again.

Well, what a waste of valuable disk space. So, after I got my new MacBook Pro, equipped with an SSD, I decided to go for it and share the Boot Camp partition between Windows 7 running natively and VirtualBox.

Actually, there exist a lot of posts on this topic already. So here’s a few I came across:

• Windows 7 on Mac OS X through Virtual Box
• Windows 7 Bootcamp Installation mit Virtual Box nutzen (in german)
• Windows7 in OSX with Bootcamp and Virtualbox
• How to run Windows 7 under Mac OS X 10.6 for free

The best and most complete one is IMHO luckypiplav’s howto, as it already covers most of the issues and caveats.

So my today’s post will be sort of an aggregate of all these posts before. I’m not trying to duplicate, my focus is to show what I had to do to get my setup working for me.

To begin with, here’s a short summary of my specs:

• Apple MacBook Pro 15″, February 2011 model, equipped with an 120 GiB SSD instead of a 500 GiB hard drive
• OS X 10.6.6 on HFS partition (80 GiB)
• Windows 7 SP 1 on Boot Camp partition (40 GiB)

Install Windows 7 through Boot Camp

I’m not going to loose big words on this. I used the Boot Camp assistant to prepare the hard drive for installation.
My hard drive was split into a 80 GiB partition for OS X and a 40 GiB partition for Windows 7.
The process is straight forward. For those not so familiar with it, here’s a howto.

After completing Windows 7 setup I first installed SP1 and all additional updates. I also activated the Windows 7 license. Then I booted right back into OS X.

Setup RAW partition access

Oh well, here’s some tech stuff to go through. This is also one of the things I dislike about all the other posts on this topic (sorry guys, I’m just honest): Everyone tells you to do some shell magic trickery, like write access to the partition device files. However, if your setup is only slightly different, you’re most likely doomed

So, let’s start on looking up the partition information first. For this you need to launch Disk Utility first.
My screen shots are from a german language OS X, but for the sake of demonstration purpose, this will be sufficient.

On the main window, click your Boot Camp partition first and the “Information” icon second.

This will reveal the partition information. The most important thing for us to work with, is the partition ID, which in my case reads “disk0s3″ (first disk, 3rd slice). In most cases this will be identical for you, but chances are, that it’s not. If it reads something different for you, then use this instead.

Now open up Terminal. Your starting directory in Terminal is usually your home directory, which evaluates to /Users/USERNAME. In my case it’s /Users/Gianpaolo. You can always verify your current location using the “pwd” (Print Working Directory) command.
I store all my VM related stuff in my home directory in a folder called “VirtualBox VMs”, so I change to this directory and create a new folder for the new Windows 7 VM.


cd "VirtualBox VMs"
mkdir Win7onMBP
cd Win7onMBP


Now, we need to grant permissions to the partition we inspected before. Rembember, mine was “disk0s3″? Don’t forget to use the one, that correctly applies to your system.
Note: You’ll be asked to enter your password to run this command:


sudo chmod 777 /dev/disk0s3


You will also need to eject the Boot Camp volume, in case it’s mounted.
Note: If you decided to format your Boot Camp partition with NTFS, then it won’t be accessible from OS X. In this case, it won’t be mounted as well. This is the case for me, so I effectively left this step out.


diskutil umount /Volumes/BOOTCAMP


To have this settings parmenently applied to the system, you will need to add them to the local boot script. For this purpose, we use the “nano” command, a simple text editor which is simpler to use then “vi”. Just type and quit using the “CTRL-X” key stroke.
Chances are that this file does not yet exist, but never mind, it’ll be created automatically.


sudo nano /etc/rc.local


Add the following text to your rc.local file:


# grant VirtualBox permissions to Boot Camp partition
#
chmod 777 /dev/disk0s3
diskutil umount /Volumes/BOOTCAMP


Again, if the Boot Camp volume is NTFS formatted, it won’t be mounted anyway, so the “diskutil” line can be omitted in this case.
Type “CTRL-X” to save and exit.

Now it’s time to create the RAW disk file for use with VirtualBox. For this, you should be inside the VM directory we created previously. If in doubt, check this using the “pwd” command. From here, run the following command:


sudo VBoxManage internalcommands createrawvmdk -rawdisk /dev/disk0 -filename win7raw.vmdk -partitions 3


Please note that this time, you won’t need to give the whole “disk0s3″ string to the command above. Instead leave the last two characters away, just stating the physical disk name, which is “disk0″. You will need however to supply the partition number “3″ taken from the “disk0s3″ string to the “-partitions” argument as seen above.

Create the VM

Simply follow the instructions of luckyviplav’s howto.

Important to note however: As of VirtualBox 4.x, the disk drives are always attached to a SATA controlled, as shown on the screenshot below.
It is effectively required to remove the disk from the SATA controller and attach it to the IDE controller as primary master instead. Also do not forget to set the IDE controller type to “ICH6″, otherwise you’ll get a “STOP: 0x0000007B” BSOD (Inaccessible Boot Device)”.

I strongly recommend to keep the SATA controller in the VM profile. This will have the SATA drivers automatically installed during your first boot.

First Boot and driver installation

So you’re now ready to boot your VM off the Boot Camp partition.
This will cetainly take a while as all the drivers need to be installed. Please take the chance to also install the VirtualBox guest additions.

Note: If you want 3D acceleration, you’ll need to install the VirtualBox drivers from safe mode (press F8 during boot to get into safe mode).

Optional: Re-attach boot drive to SATA controller

One of the most dramatic performance improvements for VirtualBox is the use of the virtual SATA controller in favor of the IDE controller.
So after you successfully installed all the drivers including the VirtualBox guest additions to your VM shut it down first. Then open your VM settings in VirtualBox and navigate to the storage controller section. Remove the hard drive from the IDE controller and re-attach it to the SATA controller. I asked you to keep it there in the first place so the drivers could be installed, remember?

During the next boot, Windows will automatically pick up the disk from the SATA controller and use this for booting.

As a result overall performance in VirtualBox will be a little snappier as with the IDE controller, which also used a bit more CPU power than the SATA controller.

So here’s finally our Windows 7 VM bootet off the Boot Camp partition. And yet, it’s still possible to run the very same Windows 7 natively by booting directly into Boot Camp.

This comes in handy in creating disk images, which can be a very time consuming task.

Let’s look at the numbers of creating a 20gig file, which fills up available disk space at once but takes about five minutes to do so. Not to forget about the I/O load the task produces, which affects performance.

[root@localhost vz]# time dd if=/dev/zero of=test1.img bs=1024k count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 321.902 seconds, 66.7 MB/s

real    5m21.903s
user    0m0.021s
sys     0m55.282s

Creating a 20gig sparse file is done almost immediately, with the difference that disk blocks are not allocated right away.

[root@localhost ~]# dd of=test2.img bs=1024k count=0 seek=20480
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.4744e-05 seconds, 0.0 kB/s

real    0m0.002s
user    0m0.000s
sys     0m0.002s

Some possible drawbacks when using sparse files:

• Peformance degredation when having multiple sparse files to which data is written randomly. This may end up in heavy fragmentation as the sparse files are likely not to be written contiguously in that case, which in term causes slow read access performance
• Race conditions when creating many sparse files which would exceed the available disk space (e.g. 20 sparse files of 20 gigs each, but the disk is only 200 gigs in size). To handle this, a special monitoring script would be needed to consider logical vs. physical space allocation.

Up until today, I always used pre-allocated disk images, but at the expense of non-usable disk space.
I think that sparse files might be a good choice actually, at least as long as there’s not much random data written to it, so the payload stays mostly identical over longer periods of time.
For sure, a sparse file used as image for a jail-based database server is definitely a bad idea.
Nevertheless, I’m keen to try and see, if this might be a considered options for some real-live scenarios.

While flipping through my CDs I stumbled accross SoftWindows95 for IRIX. I just couldn’t resist and put the flipper in, having the software installed just minutes later, only to see that I didn’t have the license any more

But there’s hope …

After some searching I found a Usenet article with a valid license of SoftWindows95. Well, I think it’s fair enough to republish this, as for one, Insignia has sold-off SoftWindows about 10 years ago, and the successor company FWB Software stopped development in 2001, furthermore that company doesn’t exist anymore as it has been sold-off, too. Well, not even SGI is able to provide a license key for a software, which is 14 years old … hm…. Well, I _think_ it’s ok, otherwise let me know …

To activate SoftWindows95 just place this text into /usr/lib/SoftWindows95/FLEXlm/license.dat:

FEATURE Insignia_SoftWindows95 insignia 4.000 01-jan-0 0 \
ECE41259D5BE4700DC27 VENDOR_STRING=”5100 0100 0000 0001″ \
HOSTID=ANY vendor_info=SOFTWINDOWS95 ISSUER=”Silicon Graphics, \
Inc.”

The license won’t show up from the GUI _but_ SoftWindows95 will work.

Considering the age of the O2 and it’s dated 200 MHz MIPS CPU the emulation speed isnt’t too bad.
I remembered it being worse than thaz, but maybe that’s just the “geekness” of having gotten something very old to work again

Basically this topic was just a follow-up to a previous post updated for VMware Server 2.0 on Debian.

In the meantime, VMware has released ESXi vor free as well, so using VMware Server maybe superseeded by choosing ESXi.

As a sidenode also consider the post at the Ubuntu forums. There’s a short howto and a script available, which eases installation procedures. Supposedly, this could be easily adapted for Debian, as both Distros share very common roots.

Since the iSCSI device offered management capabilities over serial console I though to attach it to COM1 (/dev/ttyS0) of my host system.
This is well the point when I noticed that Xen had already grabbed /dev/ttyS0. Since my host system offered only one serial port and I didn’t have a spare serial server at hands I needed to change this behaviour to get it working.

By means of ‘dmesg’ it can be easily verified if Xen grabbed the serial port:

# dmesg|grep ttyS0
Xen virtual console successfully installed as ttyS0

Then make sure you know which kernel version you’re running:

# uname -r
Linux gic-ftp-lin-001.genotec.ch 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux

Look for the corresponding kernel section in your grub.conf (or whatever boot loader you use).

title Red Hat Enterprise Linux Server (2.6.18-8.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-8.el5
        module /boot/vmlinuz-2.6.18-8.el5xen ro root=LABEL=/
        module /boot/initrd-2.6.18-8.el5xen.img

Then add the ‘xencons’ option to the module line stating the kernel arguments.

title Red Hat Enterprise Linux Server (2.6.18-8.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-8.el5
        module /boot/vmlinuz-2.6.18-8.el5xen ro root=LABEL=/ xencons=tty6
        module /boot/initrd-2.6.18-8.el5xen.img

In this case I added ‘xencons=tty6′ to have Xen grab /dev/tty6 for it’s console.

Other possibilities are:

After changing this line and rebooting the system I could finally connect my iSCSI’s serial terminal.

That’s because NVIDIA does not support Xen in the first place albeit there’s some demand for it for sure.

Luckily the only things to be changed are within the kernel interface contained in the driver package. There exist already a lot of patches on the net, I took mine from nvnews.

You can grab a copy of the patch from my site, too.

The following instructions are derived from my steps in getting NVIDIAS’s binary driver to work on Fedora Core 6 running Xen on the x86_64 platform (Intel Core 2 Duo 6420 CPU).
It was verified to work with driver version 1.0.9755 (march 29, 2007) and 1.0-9639 (may 29, 2007), both of which you can get from the NVidia website.

First you need to have some prerequisites installed on your system:

• toolchain (gcc, make, etc.)
• applicable kernel headers (I had kernel 2.6.20-1.2948.fc6xen on my system, so I installed kernel-xen-devel-2.6.20-1.2948.fc6 and kernel-xen-2.6.20-1.2948.fc6 packages)

Then the appropriate driver packages needs to be downloaded and extracted to a temporary directory:

mkdir /tmp/nv_xen
cd /tmp/nv_xen
wget http://us.download.nvidia.com/XFree86/Linux-x86_64/1.0-9639/NVIDIA-Linux-x86_64-1.0-9639-pkg2.run
/bin/sh NVIDIA-Linux-x86_64-1.0-9639-pkg2.run -x
Creating directory NVIDIA-Linux-x86_64-1.0-9639-pkg2
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 1.0-9639.

Also get a copy of the NVidia Patch for XEN:

wget http://phaq2.phunsites.net/wp-content/uploads/2007/06/nvidia_xenpatch.gz

Then change to the source directory, apply the patch and compile the driver.
The kernel source is required. If installed properly it should be located at /usr/src/kernels. If more than one exists choose the right one according to your ‘uname -r’ output.

cd NVIDIA-Linux-x86_64-1.0-9639-pkg2/usr/src/nv
zcat ../../../../nvidia_xenpatch.gz | patch -p4
[output omitted]
make SYSSRC=/usr/src/kernels/2.6.20-1.2948.fc6xen-x86_64/ module
[output omitted]
NVIDIA: left KBUILD.

If the compile run succeeds you should see the message NVIDIA: left KBUILD by the end of the output.
If anything weird happens, e.g. build process aborts, either the patch did not apply cleanly, the headers are not up to date or your sources are not configured.
In the last case a simple ‘make oldconfig’ from the kernel source directory may be enough to get it fixed.
There’s also the chance that you try this patch on a non-supported kernel source version or NVIDIA driver package which may prevent successful compilations.
Since I did not implement the patch by myself I cannot be of much help in either case.

Upon successful compilation you can install and load the driver. Verify that the driver loaded by means of ‘lsmod’.

install -D -o root -g root -m 0644 nvidia.ko /lib/modules/`uname -r`/video/nvidia.ko
depmod -a
modprobe nvidia
lsmod|grep nvidia
nvidia               7771096  22

At this point run the NVIDIA installer to get the remaining utilities.
Use the ‘no-kernel-module’ option as you installed the kernel module already.

cd ../../../
/bin/sh nvidia-installer --no-kernel-module

This is it! You are now ready to configure your X server to use the NVIDIA driver.
Stick to the docs included with the driver on how to achieve this.

This is my Xorg sample configuration with twin-view enabled accross two displays at 1280×1024 resolution.

# sample Xorg configuration file for NVIDIA graphics driver

Section "ServerLayout"
	Identifier	"Default Layout"
	Screen		0  "Screen0" 0 0
	InputDevice	"Keyboard0" "CoreKeyboard"
EndSection

Section "Module"
	Load	"dbe"
	Load	"extmod"
	Load	"record"
	Load	"xtrap"
	Load	"freetype"
	Load	"type1"
	Load	"glx"
EndSection

Section "InputDevice"
	Identifier	"Keyboard0"
	Driver		"kbd"
	Option		"XkbModel" "pc105"
	Option		"XkbLayout" "ch"
	Option		"XkbVariant" "de_nodeadkeys"
EndSection

Section "Device"
	Identifier	"Videocard0"
	Driver		"nvidia"
	Option		"TwinView" "1"
	Option		"CursorShadow" "1"
	Option		"TwinViewOrientation" "RightOf"
	Option		"MetaModes" "1280x1024,1280x1024"
EndSection

Section "Screen"
	Identifier	"Screen0"
	Device		"Videocard0"
	DefaultDepth	24
	SubSection "Display"
		Depth	24
		Modes	"1280x1024"
	EndSubSection
EndSection