Posts from the ‘Virtualisation’ Category
Interview with Damien Sandras, creator of Ekiga
As posted on the Ekiga users mailing list, this is an interesting interview conducted recently with Damien Sandras. Lots of good stuff here, from his views on the future of the project to how it compares with the default VoIP apps in Ubuntu.
OpenIndiana 151a is out – and powered by Illumos
In case you haven’t already heard, OpenIndiana development release 151a is out. The critical change in this release is that it’s now based on the Illumos kernel, developed by star ex-Sun Microsystems talent in the wake of Oracle’s compeltely styleless killing off of OpenSolaris. Substantial new features which you won’t be seeing in Solaris 11 anytime soon such as KVM support are built-in and tightly integrated. And yes, KVM support for AMD CPUs is on the way – hopefully in time for the 8-core AMD Bulldozer architecture desktop CPUs…
There are also a nice set of desktop software additions, some of which OpenIndiana and OpenSolaris before it has been needing for ages, for example a capable suite of multimedia playback applications. OpenIndiana now has dedicated SFE repositories from which VLC and Mplayer can be installed, as well as bonus goodies such as Scribus and more.
OpenIndiana download links, release notes, and SFE repository details:
http://openindiana.org/
http://wiki.openindiana.org/oi/oi_151a+Release+Notes
http://wiki.openindiana.org/oi/Spec+Files+Extra+Repository
After running 151a for a few days (the upgrade from release 148 was completely seamless by the way), I was presented with something I hadn’t seen for a long time, not since OpenSolaris development was closed off a couple years back…
KVM is coming to Illumos…
Things are about to get verrrry interesting:
https://www.illumos.org/issues/1362
Update: Bryan Cantrill makes it official: http://dtrace.org/blogs/bmc/2011/08/15/kvm-on-illumos/
Unfortunately not supported on AMD CPUs (yet), but brilliant all the same. Long-term I hope this provides a migration path from Oracle VirtualBox.
Intel makes Ars Technica staffer’s head hurt (and mine too)
Great article published recently by Ars Technica on the product differentiation methods used by Intel in the marketing and pricing of their CPUs:
Gotta agree with most of what Peter Bright has written about here. I also happen to be one of the poor saps that got caught out by Intel’s shitty marketing, having purchased an Intel quad core part that as it turned out was missing Intel VT-x. Ever since that discovery I’ve vowed to look for alternatives in future upgrades, and over the weekend I made good on this by upgrading the OpenIndiana oi_148 box to an AMD Phenom II X6. Six cores on the desktop, great for heavily threaded workloads, a no-unwelcome-surprises feature set and all for a terrific price.
Migrating an OpenIndiana zone from one system to another
The procedure for migrating an OpenSolaris Zone on a ZFS file system is not adequately documented anywhere in Oracle’s documentation set (which makes a bunch of assumptions about how the systems involved are configured), nor could I find a clearly written blog or guide anywhere on how to do this seemingly simple and straightforward task.
In this post, we are going to migrate a zone from one OpenIndiana oi_148 x86 machine (“Machine 1″) to another running the same build (“Machine 2″). Both systems are configured with a ZFS root filesystem. I’m assuming some prior basic familiarity with creating, installing, and booting zones.
Our example zone is called afterburnerzone-2. It has its zonepath on the source machine at /rpool/zones/zone_roots/afterburnerzone-2.
Click on the “view source” button for the command transcripts recreated below for the easy-to-read view.
On Machine 1:
Prepare the zone for migration on the source system
First, halt the zone, then run the detach command:
# zoneadm -z afterburnerzone-2 halt # zoneadm -z afterburnerzone-2 detach
This creates an XML file in the zone’s zonepath (named SUNWdetached.xml) containing its configuration properties – these properties (physical network interface, IP address and so forth) can be modified later using the zonecfg utility when the zone is attached on the target system.
Make ZFS snapshots of the zone’s filesystems
Recursively snapshot the ZFS filesystems relevant to our zone:
# zfs snapshot -r rpool/zones/zone_roots/afterburnerzone-2@snap1
This create snapshots of the zone’s filesystems, which in this example are:
rpool/zones/zone_roots/afterburnerzone-2
rpool/zones/zone_roots/afterburnerzone-2/ROOT
rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
We can see this in the output of zfs list -t snapshot:
# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT ... rpool/zones/zone_roots/afterburnerzone-2@snap1 0 - 34.5K - rpool/zones/zone_roots/afterburnerzone-2/ROOT@snap1 0 - 31K - rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe@snap1 0 - 3.72G -
Create archives of the snapshots in preparation for sending to the target system
The zfs send command is used to archive a ZFS dataset. We’re going to archive all three snapshots of our detached zone to separate files (these will eventually be restored on the target system):
# zfs send rpool/zones/zone_roots/afterburnerzone-2@snap1 > /export/home/davek/afterburnerzone2.snap1 # zfs send rpool/zones/zone_roots/afterburnerzone-2/ROOT@snap1 > /export/home/davek/afterburnerzone2_root.snap1 # zfs send rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe@snap1 > /export/home/davek/afterburnerzone2_root_zbe.snap1
Copy the archives to the target system
Self explanatory – in my case I simply scp the .snap files to the target system, but copying them via a USB flash drive or whatever will work fine too.
The next steps are all performed on the target system.
On Machine 2:
Import the zone on the target system
We are assuming that our zones are being stored at /rpool/zones/zone_roots on the target system, i.e. the same relative location as on our source system. Before proceeding, make sure that the rpool/zones and rpool/zones/zone_roots ZFS file systems exist – if not, you’ll need to manually create them, e.g.:
# zfs create rpool/zones # zfs create rpool/zones/zone_roots
Restore the ZFS snapshot archives
Let’s assume we have coped the archives into a user’s home directory at /export/home/davek on the target system. We now use the zfs receive command to the restore the ZFS snapshot archives into the ZFS filesystems specified (which will be created when each command is run):
# zfs receive rpool/zones/zone_roots/afterburnerzone-2 < /export/home/davek/afterburnerzone2.snap1 # zfs receive rpool/zones/zone_roots/afterburnerzone-2/ROOT < /export/home/davek/afterburnerzone2_root.snap1 # zfs receive rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe < /export/home/davek/afterburnerzone2_root_zbe.snap1
Run zfs list to verify the snapshots have been restored to the correct location:
# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool/zones 3.72G 213G 32K /rpool/zones rpool/zones/zone_roots 3.72G 213G 32K /rpool/zones/zone_roots rpool/zones/zone_roots/afterburnerzone-2 3.72G 213G 35.5K /rpool/zones/zone_roots/afterburnerzone-2 rpool/zones/zone_roots/afterburnerzone-2/ROOT 3.72G 213G 32K /rpool/zones/zone_roots/afterburnerzone-2/ROOT rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe 3.72G 213G 3.72G /rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
Change the mountpoint property for ZFS filesystems to legacy
We do this for the following restored filesystems only:
rpool/zones/zone_roots/afterburnerzone-2/ROOT
rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
# zfs set mountpoint=legacy rpool/zones/zone_roots/afterburnerzone-2/ROOT # zfs set mountpoint=legacy rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
Mount a ZFS filesystem using a legacy mount procedure
We do this for the following filesystem only:
rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
We want to mount it to /rpool/zones/zone_roots/afterburnerzone-2/root:
# mount -F zfs rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe /rpool/zones/zone_roots/afterburnerzone-2/root
Configure the zone
Using the zonecfg command, we are going to recreate the afterburnerzone-2 zone’s configuration on the target system using the configuration file generated when it was detached.
First, configure the afterburnerzone-2 zone:
# zonecfg -z afterburnerzone-2 afterburnerzone-2: No such zone configured Use 'create' to begin configuring a new zone.
Note the prompt to create a new zone – we will do this, but point to the XML file migrated across with the zone for our settings:
zonecfg:afterburnerzone-2> create -a /rpool/zones/zone_roots/afterburnerzone-2
If this is successful, you won’t see any confirmation in the positive, only an error if the preexisting zone configuration file cannot be found. By running the info command here, one can check the zone settings and they should match what was originally set on the source machine:
zonename: afterburnerzone-2
zonepath: /rpool/zones/zone_roots/afterburnerzone-2
brand: ipkg
autoboot: true
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
hostid:
fs-allowed:
net:
address: 192.168.51.14
allowed-address not specified
physical: rge1
defrouter not specified
The remaining configuration using zonecfg in this particular example involves checking the zone’s physical network interface and IP address and changing if necessary, for example, if the physical network interfaces are different on the target machine (which in this example are):
zonecfg:afterburnerzone-2> select net physical=rge0 zonecfg:afterburnerzone-2:net> set physical=bge1 zonecfg:afterburnerzone-2:net> set address=192.168.51.9 zonecfg:afterburnerzone-2:net> end zonecfg:afterburnerzone-2> info zonecfg:afterburnerzone-2> commit zonecfg:afterburnerzone-2> exit
Attach the zone
Finally, let’s attach the zone to the system:
# zoneadm -z afterburnerzone-2 attach
Log File: /var/tmp/afterburnerzone-2.attach_log.lRayVj
Attaching...
preferred global publisher: openindiana.org
Global zone version: entire@0.5.11,5.11-0.148:20101125T013212Z
Cache: Using /var/pkg/download.
Updating non-global zone: Output follows
Packages to install: 16
Create boot environment: No
Evaluation: Packages in zone afterburnerzone-2 are out of sync with the global zone. To proceed, retry with the -u flag.
Result: Attach Failed.
Okay – so let’s try again, this time using the -u flag as instructed:
# zoneadm -z afterburnerzone-2 attach -u
Log File: /var/tmp/afterburnerzone-2.attach_log.eWaWok
Attaching...
preferred global publisher: openindiana.org
Global zone version: entire@0.5.11,5.11-0.148:20101125T013212Z
Cache: Using /var/pkg/download.
Updating non-global zone: Output follows
Packages to install: 16
Create boot environment: No
PHASE ACTIONS
Install Phase 485/485
PHASE ITEMS
Package State Update Phase 16/16
Image State Update Phase 2/2
No updates necessary for this image.
Updating non-global zone: Zone updated.
Result: Attach Succeeded.
Done! We can now proceed to boot and log in to the zone.
Bordeaux for OpenIndiana part 2: Safari and VLC media player
Continuing on in my multi-part review of Bordeaux for OpenIndiana, I’m trying out a few of the supported applications to see how well they run.
I must say there are some odd inclusions to the supported applications list, amongst them VLC media player, and Apple’s Safari web browser. Practically every current desktop-ish operating system out there is guaranteed to have a media player of some sort available for it: on OpenIndiana, I use MPlayer (which runs great), and generally if you’re running desktop Linux then you’re going to have access to a whole bunch of media players capable of handling practically any codec or format imaginable – so I’m not entirely sure why VLC under Wine would be desirable, nor even something Wine development resources should be focused on. Running VLC under Bordeaux for Linux, for example, just feels a bit pointless.
Safari is a similarly baffling inclusion. The rationale is so that web designers have access to Safari to check the rendering of web pages on – but I really think any web designer remotely serious about their job (at least, serious enough to use the title “web designer”) would have access to a Mac OS X box of some sort. Furthermore, Safari itself in my opinion is just a pointless browser to support – it runs on a single platform, is controlled by a single vendor, and frankly – in this day and age of cross compatibility – is just increasingly irrelevant to me.
At any rate, the performance of both of these applications under Bordeaux on OpenIndiana leaves plenty to be desired. VLC wouldn’t install at all using the standard Bordeaux GUI: I believe Bordeaux references download locations on the actual source vendors’ sites, and if the vendor changes these at all then the installer ceases to work: unfortunately, the Bordeaux installer GUI does not give sufficient feedback that this is the case. After manually downloading and installing VLC 1.1.0 for Windows under Bordeaux, I immediately noticed graphical artifacts in the VLC GUI:
Interestingly, actual movie quality seemed to be degraded compared to the same file being played back under a native media player. In the below grab, a native media player is on the left, with the same movie being played back under VLC on Bordeaux on the right – click to zoom:
Regarding Safari, the application appeared to install, but when attempting to view bookmarks, or perform other certain commands, the application would crash:
Even worse, it would then screw up the windowing system, requiring manual killing of the wine processes:
Finally, I could never actually get to any sites, internal or external, even though internet connectivity on the host was fine.
My suggestion to the Bordeaux developers would be to simply remove these redundant applications from the supported applications list, and focus on getting core business applications such as Microsoft Office working seamlessly under Bordeaux. Even if someone out there really does have a use for VLC or Safari under Wine, then it’s imperative to have these applications running smoothly in a shipping product: my initial impressions are that there are several areas where things aren’t quite ready for prime time.
Bordeaux for OpenIndiana: a commercial Wine implementation
I’ve written before about using Wine to run various old games and Windows apps on non-Windows platforms without the hassle, performance penalty and cost of using a full desktop virtualization application.
I’ve decided to check out (and review!) a commercial Wine offering for .nix platforms called Bordeaux. There are several interesting things about Bordeaux: it’s affordable; the company claims stability for a varied albeit small set of Windows applications (Microsoft Office 2007, Adobe Photoshop CS2, Internet Explorer, VLC media player, etc.); and perhaps most intriguingly, it appears to be the first commercial application out there to recognise OpenIndiana and to offer a distinct OpenIndiana installer accordingly. Promising stuff, so let’s dig into the installation process.
I am performing this on an Intel Q8200 system running OpenIndiana release oi_147.
I checked out a copy of Bordeaux for OpenIndiana from Bordeaux Technology Group’s online store. A few minutes later I was sent a download link: the installer is 103.5MB, and consists of a single shell script with no accompanying documentation. A readme with the latest release notes and the installation procedure here would be useful, even just a mirror to what is found on their website.
After making the installation script executable, I ran it and immediately had a problem. The script apparently uses GNU tar, and on my system /usr/bin is first in my PATH, not /usr/gnu/bin. Altering my PATH so that GNU utilities are looked at first allowed the installation script to proceed.
Post-install, I noticed that the Bordeaux directory and contents created at /opt/bordeaux were owned by a non-existent 101 user (no such user on my system). Again, a manual change in ownership was required here.
Other than that, Bordeaux application entries were created in GNOME, and selecting a Windows application installation command gave me an instant idea of what the supported applications are (below).
Next step is to try out a few of the supported Windows apps. Stay tuned.
Secure remote desktop using SSH and VNC
University of Pennsylvania Biology Department have a great how-to for using SSH with port forwarding and VNC to create a no-cost secure remote desktop application. Although it’s a Mac OS-specific article, the basics work great on other OSs too, and I use this to remotely administer both Mac OS and OpenIndiana machines.
The article is here: http://www.bio.upenn.edu/computing/network/remote.vnc.osx.php
Can’t be beat for remote assistance on the cheap.
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:
Yes, we want to use the machine that is powered on and running the vCenter application itself:
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”:
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:
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:
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:
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:
