Virtualisation

AMD “Piledriver” FX-8350 on OpenIndiana

Posted by davekoelmeyer on October 24, 2012
Posted in: AMD, Illumos, OpenIndiana, VirtualBox, Virtualisation. Tagged: , , , , . 5 comments

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.

About these ads

HP ProLiant ML110 G7 server – a short review

Posted by davekoelmeyer on October 18, 2012
Posted in: Hardware, KVM, Open Source, OpenIndiana, Virtualisation. Tagged: , , , . 4 comments

I’ve recently acquired an HP ProLiant ML110 G7 tower server for evaluating for use in a small business environment, specifically running OpenIndiana. Following are a few short notes regarding my impressions of the box.

Pros:

Price-wise, for the base spec model, in my case with the Intel Xeon E3-1220 CPU, it’s an incredible bargain (and even more so bearing in the mind the below pros). Consider that even with an 8GB RAM upgrade and dual 1TB drives it’s not that much more than say a well-specced Dell business desktop PC.

It’s built like a tank. Nothing chintzy about the materials, nothing flexes, wobbles, rattles. In short, it oozes build quality.

Access to user-expandable options is super easy, as you’d expect.

There is ECC RAM support – ideal for extra peace of mind when using ZFS storage arrays. On that note, OpenIndiana oi_151a7 installs and runs just fine, with no driver nor hardware issues out of the box. Installing KVM on OpenIndiana, and installing and booting guest VMs poses no problem – it “just works”.

Dual Gigabit Ethernet ports are standard.

A Lights Out Manager is also included as standard. Sadly, the remote console functionality is a paid extra, but the included remote power management and monitoring functionality is quite impressive.

HP Lights Out Management interface

Cons:

Remote console, remote virtual media and other LOM options are sadly licensed extras. Unless you pay extra for this expect to potentially be making site visits from time to time. Kinda wish HP would just throw this in with the LOM as standard – Sun did, for instance.

There is nothing much in the way of physical redundancy for the server in its base spec.

One review made mention of the ML110′s quiet operation and how it would not be noticed in an office environment. Well, unless your office happens to be on the factory floor of an air conditioning manufacturing plant, you’re going to notice this thing…

Maximum physical RAM capacity is 16GB, which is a tad on the small size.

And although I haven’t checked, extending the warranty out from the standard one year period would probably cost a fair bit.

Interview with Damien Sandras, creator of Ekiga

Posted by davekoelmeyer on October 30, 2011
Posted in: Android, Conferencing, Ekiga, Gnome, Linux, Open Source, Virtualisation. Leave a Comment

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.

http://www.josetteorama.com/interview/ekiga-open-source-softphone-video-conferencing-and-instant-messenger/

OpenIndiana 151a is out – and powered by Illumos

Posted by davekoelmeyer on September 29, 2011
Posted in: Virtualisation, OpenSolaris, Solaris, Oracle, Open Source, Scribus, Gnome, Illumos, OpenIndiana, AMD. 1 comment

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…

OpenIndiana update manager

KVM is coming to Illumos…

Posted by davekoelmeyer on August 14, 2011
Posted in: Illumos, Open Source, OpenIndiana, OpenSolaris, Oracle, Virtualisation. Leave a Comment

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)

Posted by davekoelmeyer on August 9, 2011
Posted in: AMD, Illumos, OpenIndiana, Virtualisation. 1 comment

Great article published recently by Ars Technica on the product differentiation methods used by Intel in the marketing and pricing of their CPUs:

http://arstechnica.com/gadgets/news/2011/08/what-processor-should-i-buy-intels-crazy-pricing-makes-my-head-hurt.ars

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.

AMD Phenom II X6

AMD Phenom II X6 - cores working in OpenIndiana

Migrating an OpenIndiana zone from one system to another

Posted by davekoelmeyer on June 5, 2011
Posted in: Open Source, OpenIndiana, OpenSolaris, Oracle, Virtualisation. Leave a Comment

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.

 

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 one 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

Posted by davekoelmeyer on April 19, 2011
Posted in: OpenIndiana, Virtualisation, Wine. 2 comments

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:

VLC user interface problems

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:

VLC on Bordeaux

 

Regarding Safari, the application appeared to install, but when attempting to view bookmarks, or perform other certain commands, the application would crash:

Safari crashing - part 1

Even worse, it would then screw up the windowing system, requiring manual killing of the wine processes:

Safari crashing - part 2

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.

See also: http://davekoelmeyer.wordpress.com/2011/03/17/bordeux-for-openindiana-a-commercial-wine-implementation/

Bordeaux for OpenIndiana: a commercial Wine implementation

Posted by davekoelmeyer on March 17, 2011
Posted in: OpenIndiana, Virtualisation, Wine. 2 comments

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).

Bordeaux Installed on OpenIndiana

Bordeaux supported applications

Next step is to try out a few of the supported Windows apps. Stay tuned.