Seems that Oracle is busy pushing the boundaries of all that is disingenuous – as usual…
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:
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:
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…
Things are about to get verrrry interesting:
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.
Finally, great news on the OpenIndiana and Illumos front:
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 :)
…by those who know it best, in this case Eric Schrock:
“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!”
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.
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!
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:
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:
# 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:
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: email@example.com,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: firstname.lastname@example.org,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.
Great tweet from Bryan Cantrill here, and yet another example of the level of community involvement we’ve come to expect from Oracle: