Category Archives: VirtualBox

AMD “Piledriver” FX-8350 on OpenIndiana

FX-8350 unboxed

I’ve recently acquired a brand-spanking-new AMD FX-8350 CPU as an upgrade to my Phenom II X6 box. All the recent benchmarks of this CPU seem to fairly consistently point to it being a multithreaded monster. Plus, AMD has dropped the price of the new FX CPUs compared to the original Bulldozer architecture parts – and the icing on the cake is that the upgrade path is as simple as performing a BIOS update on my budget ASRock motherboard, and swapping out the old CPU for the new. Bliss!

So, given that AMD’s Piledriver archtecture might be a bit of an unknown as far as compatibility with Illumos and OpenIndiana goes, how does it fare? Well, the system seems to boot fine and run: here is the CPU as detected by Peter Tribble’s Solview app:

FX-8350 detected by Solview

8 cores, running at 4.0GHz – good. Let’s throw half a dozen VMs its way and see what happens:

VirtualBox VMs and the FX-8350

CPU utilization as measured by Solview is in the foreground. I should mention that this is also with a couple of OpenIndiana Zones running: GlassFish serving up a wiki, and a local BIND resolver.

In the time since I’ve installed the CPU I’ve experienced a couple of system freezes, so I’ve disabled core power saving features in BIOS to see if that changes anything. Yes, this is a new CPU architecture on a development build of an OS, but all in all, it’s working fairly well. Assuming I can iron out any stability issues, the FX-8350 is easily an incredible bargain.

Update 1: After further investigating the system hanging issues, it’s not limited to OpenIndiana, and is also encountered with Ubuntu Linux installed. Further updates to happen as I get to the bottom of this 🙂

Update 2: See here.

Advertisements

Oracle Acquired Innovation: How It Works

Convert a physical PC into a VirtualBox virtual machine

This seems to be a fairly popular topic out there, so I thought I’d share my little how-to. It’s not really different to other guides you may read, but given Oracle’s inevitable imminent alienation of the VirtualBox community, the inevitable jacking up of the support costs, the inevitable stifling of development resources and feature enhancements followed by the inevitable fork (perhaps with some patent litigation thrown in for good measure), what better time to try it out? 🙂

 

My test source physical machine is an old Pentium 4 box running Windows XP Home SP3. It contains a single 75GB HDD, itself holding a single partition occupying the whole disc. Nothing fancy. The objective is to convert the machine into a VMware VMDK image file, then import that into VirtualBox (in this case, version 3.1.4 running on an OpenIndiana oi_147 host). According to the VirtualBox user manual, the VMDK format is fully supported by VirtualBox. If you’re trying this out yourself, note that in this guide I’m assuming prior basic familiarity with creating VMs in VirtualBox.

Our first step is to download and install the free VMware vCenter Converter Standalone application on the physical source PC. You can grab it from the following location – but note you will need to create an online account and register to receive a download link (yuck):

http://www.vmware.com/products/converter/

After downloading, simply step through the installation wizard defaults – there are no surprises nor quirks to note.

 

Once installed, let’s run the vCenter Converter application, and convert our machine to a virtual clone:

vCentre - convert a machine...

Yes, we want to use the machine that is powered on and running the vCenter application itself:

vCenter - powered on local machine...

For now I am saving the clone to the HDD of the machine I am cloning from – we are going to resize the clone’s HDD size, so we won’t have any space issues (obviously use a larger physical disc, pop another disc in the machine, or save to large external storage otherwise). Note that we using VMware Workstation 7.0.x file format, and the name of our clone is “cybernoid-virtual”:

vCenter destination settings

In the Options screen that follows, click on the “Data to copy” entry on the left hand side pane, and on the right hand side click on “Advanced…”, where we can get at the disc resize settings:

vCenter advanced options

We have resized the destination (clone) HDD to be 20GBs (with the “type” set to “not pre-allocated”). Also, for the other options available in this screen, we have specified a single CPU, 500MB of RAM, and NAT networking. Make a note of these latter options and their settings, as we’ll need to manually enter them into VirtualBox when recreating the virtual machine there:

vCenter options

That’s all I configured here, leaving everything else at the defaults, and letting the application clone the physical machine (which took about an hour).

 

At the end of the process, vCenter Converter had created a folder containing the critical cybernoid-virtual.vmdk file. I copied this file over to my OpenIndiana machine, fired up VirtualBox 3.1.8, and imported it using the VirtualBox Virtual Media Manager.

I then used the VirtualBox New Virtual Machine Wizard to create a Windows XP virtual machine, pointing to the .vmdk file to use for its virtual hard disc. I was careful to set it to use 500MB of memory, and only a single CPU.

 

Finally firing it up, I was met with a VirtualBox splash screen, followed by a blank, black screen with no other activity. Although the VM reported a status of “Running” it was clearly failing to boot at all. Referring to the VirtualBox Windows migration how-to here…

http://www.virtualbox.org/wiki/Migrate_Windows

…I came across the following section:

“…If you perform a Windows installation with default settings in VirtualBox, Halacpi.dll will be chosen as VirtualBox enables ACPI by default but disables the IO APIC by default. A standard installation on a modern physical PC or VMware will usually result in Halaacpi.dll being chosen as most systems nowadays have an IO APIC and VMware chose to virtualize it by default (VirtualBox disables the IO APIC because it is more expensive to virtualize than a standard PIC). So as a first step, you either have to enable IO APIC support in VirtualBox or replace the HAL. Replacing the HAL can be done by booting the VM from the Windows CD and performing a repair installation…”

Rather than shag around with a repair installation, I simply enabled IO APIC in the VirtualBox settings for the machine, and bingo:

Cloned VM running in VirtualBox

My host machine is an Intel Q8200 which doesn’t have Intel VT-x (thanks so much, Intel…), but even so, performance is pretty good.

 

I also tried the above procedure to create a virtual clone of a laptop running Windows 7 64 bit. It also worked fine, but only after using an IDE storage controller to attach the VMDK to in the VirtualBox settings for the VM – using SATA, the VM would refuse to boot without a BSOD:

VirtualBox storage controller settings

Windows 7 VirtualBox guest

Use NFS to create a VirtualBox “shared folder” for a FreeBSD 8.0 Guest

Whilst tinkering with NFS, I found a neat application for the lack of shared folders support for my FreeBSD 8.0 VirtualBox guest running in an OpenSolaris host. Although there is a FreeBSD port of VirtualBox Guest Additions, it doesn’t seem to do too much else other than enable seamless host/guest mouse integration.

This is an insecure configuration, and I certainly would not recommend running it on anything other than a private configuration. All the same, this works quite well for me, so may be of use for someone else.

I’m using an OpenSolaris snv_134 x64 host, running VirtualBox 3.1.6 with a FreeBSD 8.0 x86 guest machine installed configured according to https://davekoelmeyer.wordpress.com/2010/03/31/freebsd-8-0-x86-and-kde4-full-screen-in-virtualbox-3-1-4/. The name of my host serving up NFS exports is afterburner.

 

Let’s configure the OpenSolaris host for NFS. First, create an NFS share point named “testshare” at /export:

$ pfexec mkdir /export/testshare
$ pfexec chmod 777 /export/testshare

 

Create an NFS share group named “testgroup”, and verify the operation:

$ pfexec sharemgr create testgroup

$ sharemgr list -v                
default	enabled	nfs
zfs	enabled	
testgroup	enabled	nfs

 

Add the share /export/testshare to the share group “testgroup”, and verify the operation:

$ pfexec sharemgr add-share -s /export/testshare -d "this is a test NFS share" testgroup

$ sharemgr show -v                                                                      
default
zfs
testgroup
	  /export/testshare	"this is a test NFS share"

$ share
-@testgroup     /export/testshare   rw   "this is a test NFS share"

 

Now, configure FreeBSD to automagically mount the NFS share when accessed, using amd (no, not that one). This is a modification of the very helpful guide here, and I agree with that author’s assertion that documentation for those new to amd is somewhat lacking.

 

So, enable amd in FreeBSD by adding amd_enable=”YES” and amd_flags=”” to /etc/rc.conf. My /etc/rc.conf file (in total) reads:

# -- sysinstall generated deltas -- # Sun Mar 28 04:08:02 2010
# Created: Sun Mar 28 04:08:02 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
amd_enable="YES"
amd_flags=""
local_startup="${local_startup} /usr/local/kde4/etc/rc.d"
kdm4_enable="YES"
hald_enable="YES"
dbus_enable="YES"
vboxguest_enable="YES"
hostname="freebsd"
ifconfig_em0="DHCP"
keymap="us.iso"
moused_enable="YES"
sshd_enable="YES"

 

Create the file /etc/amd.conf containing the following:

[global]
auto_dir        = /.amd
log_file        = /var/log/amd.log
log_options     = error,fatal,warning
map_type        = file
search_path     = /etc

[/nfs]
map_name        = amd.nfs

 

Create the file /etc/amd.nfs containing the following (this should be all on one line, but for blog formatting sake I have added a line break directly after the first equals sign, and there should be no space between it and the following double quotation mark):

testshare  fs:=${autodir}${path};type:=program;mount:=
"/sbin/mount mount -t nfs -o rw,-N afterburner:/export/testshare ${fs}";

(Note that afterburner is the name of my host system serving up the NFS export, and I’ve added this to my FreeBSD guest’s hosts file at /etc/hosts. You would of course modify this to suit your own setup.)

 

Finally, start the amd daemon:

# /etc/rc.d/amd start

 

Now, in the FreeBSD guest open up a terminal and cd to /nfs/testshare. amd should mount the location as an NFS share automagically, and you can now exchange files between the VirtualBox host and guest environments.

For ease-of-use I’ve created a symlink on the respective desktops of my host and guest OSs:

NFS shared folder between OpenSolaris and FreeBSD