Category Archives: OpenSolaris

Oracle Solaris 11 has no license fees!!

Seems that Oracle is busy pushing the boundaries of all that is disingenuous – as usual…

Solaris 11 license fees

Solaris 11 runs on any system

Advertisements

“Fork Yeah! The Rise & Development of illumos”

Great presentation here from Bryan Cantrill (formerly of Sun, currently at Joyent) about the story behind illumos. Some great comments on the (destructive) role management and marketing can play in innovation, related comments about how badly Oracle don’t get this (and never will really), and a few fascinating tidbits about the history of Solaris at Sun to boot.

Updated: the video itself is now available:

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…

OpenIndiana update manager

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.

OpenIndiana based on Illumos is almost here!!

Finally, great news on the OpenIndiana and Illumos front:

http://twitter.com/#!/openindiana/statuses/93806371002265600

So, this means the first official development release of OpenIndiana based on Illumos is imminent, the latter being the first truly open-sourced, community-driven Solaris-derived kernel. This is big, big news, as many of Sun Microsystems’ brightest engineers have worked on Illumos via the companies they have since joined (ex-Oracle…) that are actively using Illumos for their business.

Seriously, I can’t wait 🙂

Yet another scathing appraisal of how Oracle is handling Solaris…

…by those who know it best, in this case Eric Schrock:

http://dtrace.org/blogs/eschrock/2011/05/31/beyond-oracle/

“It is with a sad heart, however, that I look at the work so many put into making OpenSolaris what it was, only to see it turned into the next HP-UX – a commercially relevant but ultimately technologically uninteresting operating system. This is not to denigrate the work of those at Oracle working on Solaris 11, but I personally believe that a truly innovative OS requires an engaged developer base interacting with the source code, and unique technologies that are adopted across multiple platforms. With no one inside or outside of Oracle believing the unofficial pinky swear to release source code at some abstract future date, many may wonder what will happen to the bevy of cutting edge technologies that made up OpenSolaris.

“…suffice to say that OpenSolaris is alive and well outside the walls of Oracle, so give it a spin and get involved!”

Amen.

Illumos Panel Discussion – some highlights

Really interesting set of videos recorded during a recent gathering of the minds behind the companies developing and using Illumos, including Garrett D’Amore (of Nexenta), Adam Leventhal (of Delphix) and Bryan Cantrill (of Joyent), amongst others. These people represent the star talent behind some revolutionary technology developed at Sun Microsystems as used in Solaris and OpenSolaris.

You can find the full set of videos on DeirdrĂ© Straughan’s YouTube channel. I found the comments made in the fifth part especially juicy:

An excerpt of some of the comments:

“What I’ve seen on the mailing list is actually a higher level of support than I think frankly Oracle’s own customers were getting at Oracle…if you ask a question about DTrace, you’re going to get the authors of DTrace involved very often, just by asking a question on the list.” Garrett D’Amore (asked about support)


“Right now…we have extensions to DTrace for example that cannot go back into Solaris. Oracle would be violating – in an act of poetic justice – the license that they themselves created, if they took that back.”
– Bryan Cantrill


“They’ve made a lot of changes
[in Solaris 11] that frankly I would not take, that I think are unnecessary changes. Solaris 11 I think is going to be a real opportunity for Illumos.” – Bryan Cantrill


“It
[Solaris 11] represents a huge departure from Solaris 10. So, it’s going to ask the customers who are on Solaris 10 ‘do you want to invest a tremendous amount of time going to Solaris 11, going to Linux, or going to something else?’.” – Adam Leventhal


“Solaris 11 is mutating into what some people would call the bootloader for the Oracle database. Oracle’s priorities are clearly way different from what Sun’s were…I would not be entirely unsurprised if it turns that out you can’t actually license Solaris 11 separately…I would be actually very surprised if there’s ever a Solaris 12.”
– Garrett D’Amore


“There’s a huge installed base of Sun hardware out there in datacenters around the world, billions of dollars worth of equipment, and Oracle has basically given it the finger.”
– Garrett D’Amore

“Oracle has removed sun4u from Solaris 11. So there is no sun4u support in Solaris 11, which means that there is this huge amount of hardware, this installed base (anything earlier than a year or two ago) that can’t run, will not run Solaris 11 at all. And that’s a huge Illumos opportunity.” – Bryan Cantrill and Adam Leventhal

 

Meanwhile, Larry Ellison is suing his neighbour over some trees blocking his view.

 

Illumos / OpenIndiana podcast

Illumos logo

Garrett D’Amore has posted an interview made of him and Alasdair Lumsden (of OpenIndiana) by Constantin Gonzalez. (Constantin has always struck me as a pretty cool guy, so much so that he’s been in my blogroll ever since starting this blog.)

The first few minutes of the podcast are in German, but the interview itself is in English. Encounraging listening!

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.

 

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.

Oracle killing bugs.opensolaris.org?

Great tweet from Bryan Cantrill here, and yet another example of the level of community involvement we’ve come to expect from Oracle:

Bryan Cantrill's Tweet...

http://twitter.com/#!/bcantrill/statuses/67743384848183296