I have had a busy couple of months. After wrapping up work on Solaris 8 Containers (my teammate Steve ran the Solaris 9 Containers effort), I turned my attention to helping the Image Packaging team (rogue's gallery) with their efforts to get OpenSolaris 2008.05 out the door.

Among other things, I have been working hard to provide a basic level of zones functionality for OpenSolaris 2008.05. I wish I could have gotten more done, but today I want to cover what does and does not work. I want to be clear that Zones support in OpenSolaris 2008.05 and beyond will evolve substantially. To start, here's an example of configuring a zone on 2008.05:

# zonecfg -z donutshop
donutshop: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:donutshop> create
zonecfg:donutshop> set zonepath=/zones/donutshop
zonecfg:donutshop> add net
zonecfg:donutshop:net> set physical=e1000g0
zonecfg:donutshop:net> set address=129.146.228.5/23
zonecfg:donutshop:net> end
zonecfg:donutshop> add capped-cpu
zonecfg:donutshop:capped-cpu> set ncpus=1.5
zonecfg:donutshop:capped-cpu> end
zonecfg:donutshop> commit
zonecfg:donutshop> exit

# zoneadm list -vc
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - donutshop        configured /zones/donutshop               ipkg     shared

If you're familiar with deploying zones, you can see that there is a lot which is familiar here.  But you can also see that donutshop isn't, as you would normally expect, using the native brand. Here we're using the ipkg brand. The reason is that commands like zoneadm and zonecfg have some special behaviors for native zones which presume that you're using a SystemV Packaging based OS. In the future, we'll make native less magical, and the zones you install will be branded native as you would expect. Jerry is actually working on that right now. Note also that I used the relatively new CPU Caps resource management feature to put some resource limits on the zone-- it's easy to do!. Now let's install the zone:

# zoneadm -z donutshop install
A ZFS file system has been created for this zone.

      Image: Preparing at /zones/donutshop/root ... done.
    Catalog: Retrieving from http://pkg.opensolaris.org:80/ ... done.
 Installing: (output follows)
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  49/49   7634/7634 206.85/206.85 

PHASE                                        ACTIONS
Install Phase                            12602/12602 

       Note: Man pages can be obtained by installing SUNWman
Postinstall: Copying SMF seed repository ... done.
Postinstall: Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=681
Postinstall: Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=741
       Done: Installation completed in 208.535 seconds.

 Next Steps: Boot the zone, then log into the zone console
             (zlogin -C) to complete the configuration process

There are a couple of things to notice, both in the configuration and in the install:

Non-global zones are not sparse, for now

Zones are said to be sparse if /usr, /lib, /platform, /sbin and optionally /opt are looped back, read-only, from the global zone. This allows a substantial disk space savings in the traditional zones model (which is that the zones have the same software installed as the global zone).

Whether we will ultimately choose to implement sparse zones, or not, is an open question. I plan to bring this question to the Zones community, and to some key customers, in the near future.

Zones are installed from a network repository

Unlike with traditional zones, which are sourced by copying bits from the global zone, here we simply spool the contents from the network repository. The upside is that this was easy to implement; the downside is that you must be connected to the network to deploy a zone. Getting the bits from the global zone is still desirable, but we don't have that implemented yet.

By default, zones are installed using the system's preferred authority (use pkg authority to see what that is set to). The preferred authority is the propagated into the zone. If you want to override that, you can specify a different repository using the new -a argument to zoneadm install:

# zoneadm -z donutshop install -a ipkg=http://ipkg.eng:80

Non-global zones are small

Traditionally, zones are installed with all of the same software that the global zone contains. In the case of "whole root" zones (the opposite of sparse), this means that non-global zones are about the same size as global zones-- easily at least a gigabyte in size.

Since we're not supporting sparse zones, I decided to pare down the install as much as I could, within reason: the default zone installation is just 206MB, and has a decent set of basic tools. But you have to add other stuff you might need. And we can even do more: some package refactoring should yield another 30-40MB of savings, as packagings like Tcl and Tk should not be needed by default. For example, Tk (5MB) gets dragged in as a dependency of python (the packaging system is written in python); Tcl (another 5MB) is dragged in by Tk. Tk then pulls in parts of X11. Smallness yields speed: when connected to a fast package repository server, I can install a zone in just 24 seconds!.

I'm really curious to know what reaction people will have to such minimalist environments. What do you think?

Once you start thinking about such small environments, some new concerns surface: vim (which in 2008.05 we're using as our vi implementation) is 17MB, or almost 9% of the disk space used by the zone!

Non-global zones are independent of the global zone

Because ipkg zones are branded, they exist independently of the global zone. This means that if you do an image-update of the global zone, you'll also need to update each of your zones, and ensure that they are kept in sync. For now this is a manual process-- in the future we'll make it less so.

ZFS support notes

OpenSolaris 2008.05 makes extensive use of ZFS, and enforces ZFS as the root filesystem. Additional filesystems are created for /export, /export/home and /opt. Non-global zones don't yet follow this convention. Additionally, I have sometimes seen our auto-zfs file system creation fail to work (you can see it working properly in the example above). We haven't yet tracked down that problem-- my suspicion is that there is a bad interaction with the 2008.05 filesystem layout's use of ZFS legacy mounts.

As a result of this (and for other reasons too, probably), zones don't participate in the boot-environment subsystem. This means that you won't get an automatic snapshot when you image-update your zone or install packages. That means no automatic rollback for zones. Again, this is something we will endeavor to fix.

Beware of bug 6684810

You may see a message like the following when you boot your zone:

zoneadm: zone 'donutshop': Unable to set route for interface lo0 to éÞùÞ$
zoneadm: zone 'donutshop': 

This is a known bug (6684810); fortunately the message is harmless.

In the next month, I hope to: take a vacation, launch a discussion with our community about sparse root zones, and to make a solid plan for the overall support of zones on OpenSolaris. I've got a lot to do, but that's easily balanced by the fact that I've been having a blast working on this project...

(2008-05-12 06:16:16.0) Permalink Comments [16]
Tags: opensolaris solaris zones
Trackback: http://blogs.sun.com/dp/entry/a_field_guide_to_zones

Looks like Alfred's hard work has paid off.  You can pull down a package of Songbird for OpenSolaris (see Alfred's blog entry for the links).  Songbird is a next-gen media player built atop the Mozilla platform.   Although I've had it crash once, on the whole it has worked quite well.  SteveL's mashtape extension is really neat, and you can see it in action in the screenshot below (it's the thing offering pictures, youtube videos, etc. at the bottom of the window).

Next steps would be to get this into the OpenSolaris package repository-- I hope that someday soon you will be able to pkg install songbird.

Nice work guys!

(2008-05-11 23:09:16.0) Permalink Comments [2]
Trackback: http://blogs.sun.com/dp/entry/songbird_for_solaris

In the flurry of today's launch event, we've launched Solaris 8 Containers (which was previously called Solaris 8 Migration Assistant, or Project Etude).  Here is the datasheet about the product.  Even better: We've also announced that Solaris 9 Containers will be available soon!  Jerry and Steve on the containers team have been toiling away like mad to make this possible.

Why the rename?  Well, for one thing, it's easier to say :)  It also signals a shift in the way Sun will offer this technology to customers:

• Professional Services Engagement: No longer required, now recommend.  It's also simpler to order a SunPS engagement for this product.
  
• Partners: (Some of) Sun's partners are now ready to deliver this solution to customers.  Talk to your partner for more information.
• Right to Use: Previously, we provided a 90 day evaluation RTU.  Now, the RTU is unlimited.  However, you must still pay for support.
  

I invite you to download Solaris 8 Containers, and give it a try! And as always, talk to your local SE or Sales Rep if you're interested in obtaining support licenses (or any kind of help with) your Solaris 8 (or 9) containers.

Here's Joost, our fearless marketing leader, with an informative talk about the why and how of Solaris 8 Containers. 

(2008-04-10 01:36:10.0) Permalink Comments [8]
Tags: containers solaris solaris8 virtualization zones
Trackback: http://blogs.sun.com/dp/entry/solaris_8_containers_solaris_9

I have spent a lot of time in recent months helping the IPS project.  This week I integrated usability improvements, and tracked down two different performance problems.  The first was notable because I think it's the kind of thing that would have been hard to find without DTrace.   Here's a writeup I did, cribbed from the bug report:

While doing work on IPS I discovered a large number of system calls being made during the "creating plan" phase of a fresh installation of the 'redistributable' cluster of packages.

I used the following crude dtrace script to track down the problem:

#!/usr/sbin/dtrace -Fs

python$1:::function-entry
/copyinstr(arg1) == $$2/
{
        self->t=1;
        calls++;
}

python$1:::function-return
/copyinstr(arg1) == $$2 && self->t/
{
        self->t=0;
}

syscall:::entry
/self->t/
{
        @a[probefunc]=count()
}

END
{
        printf("calls: %d", calls);
}

No points for elegance but it works.

Successive guesses allowed me to narrow this down to the get_link_actions() routine. Here's an example of its system call impact during the following sequence:

# rm -fr /tmp/foo
# export PKG_IMAGE=/tmp/foo
# pkg image-create -a foo=http://ipkg.eng /tmp/foo
# pkg install -n redistributable

I ran the D script as follows:

$ dtrace -s /s4pyfunc.d `pgrep client` get_link_actions

And once the command was done, got this output:

CPU     ID                    FUNCTION:NAME
  0      2                             :END calls: 880

  brk                                                              26
  stat64                                                       774400
  close                                                        775280
  fcntl                                                        775280
  fsat                                                         775280
  fstat64                                                      775280
  getdents64                                                  1553200

So here we can see that something is amiss-- this routine is the source of 4.7 million syscalls. Here's the code:

        def get_link_actions(self):
                """ return a dictionary of hardlink action lists indexed by
                target """
(a)             if self.link_actions:
                        return self.link_actions

                d = {}
                for act in self.gen_installed_actions():
                        if act.name == "hardlink":
                                t = act.get_target_path()
                                if t in d:
                                        d[t].append(act)
                                else:
                                        d[t] = [act]

                self.link_actions = d
                return d

When Bart and I first looked at this, it seemed by inspection to be working as designed-- the first time the routine is called, we populate a cache, and subsequently the cache is returned. At some point Bart went "Aha!" and we realized that the problem here was that the comparison at (a) wasn't working right, and that, for a not-yet-installed image, the link_actions dictionary is exactly equal to {}, the empty dictionary. That evaluates to "false" in python. So we always think that we haven't yet filled out the link_actions cache, and go to fill it. That sends us into gen_installed_actions(), which is expensive. It seems to get more and more expensive as we accumulate more manifests, as well.

So, while there are exactly zero link actions we need to worry about, we rescan all manifests for every new manifest we evaluate.

This is a situation which will crop up most often with zones, since that's the place we're most likely to create new images from scratch.

The fix is very simple: set self->link_actions to None initially (in the object constructor), and change the comparison at (a) to test against None explictly.

Having fixed this, the impact of get_link_actions is:

CPU     ID                    FUNCTION:NAME
  0      2                             :END calls: 880

  stat64                                                            3
  close                                                             4
  fcntl                                                             4
  fsat                                                              4
  fstat64                                                           4
  getdents64                                                        8

Or, basically, nothing. In some informal testing I got these numbers with ptime(1): Before:

real     1:26.730
user     1:10.988
sys        11.624

After:

real     1:12.932
user     1:02.475
sys         6.361

Or about a 19% improvement in real time. And quite a bit in sys time. Not a huge win, but not too shabby either.

I used the same technique to find a similar bug in another part of the code, but alas, Danek had already found the same bug, so I can't claim it.

(2008-04-04 18:10:51.0) Permalink Comments [3]
Tags: dtrace ips python
Trackback: http://blogs.sun.com/dp/entry/finding_bugs_in_python_code

The results of the OpenSolaris Elections are in.  Congratulations to the new board members!

So why did I entitle this post Elections Disappointment?  My complaint is with the "community priorities" question which was asked; this was a chance for core contributors to indicate what they felt were pressing priorities.  I was not happy with the OGB's choice (which I didn't know about until I voted) to reuse the same set of priorities questions from last year.  One of which was:

• Deploy a public code review facility on opensolaris.org

Which was subsequently identified by voters in this election as the #3 priority.  Did the OGB believe that we did not accomplish this goal in the past year?  I know that I took the results of the last poll (it was voted #3 in that poll, too) to heart, and worked hard to make that goal a reality, publicized it using the official channels, and have been enhancing it and taking care of it since that time, mostly on my own time.  I felt that my contribution was really undermined by the question.

Second: Who voted for this item as a priority?  If you voted for this as a priority, I would like to hear why you did (anonymously is fine).  Are you unaware that cr.opensolaris.org exists?  Are you unsatisfied with the service it provides?

I hope the new OGB will find a way to reformulate a more cogent poll question about priorities.

(2008-03-28 16:26:55.0) Permalink Comments [6]
Tags: code codereview cr.opensolaris.org opensolaris review
Trackback: http://blogs.sun.com/dp/entry/opensolaris_elections_disappointment

For the past couple of weeks, I have been working late at night and on weekends to add an ATOM feed (i.e. blog feed) to cr.opensolaris.org, so that as people post new code reviews, they are automatically discovered and published.  Stephen has been heckling me to do this work for more than a year.  This weekend I managed to finish it, despite the incredibly nice weather in the bay area: I was stuck inside with a nasty cold.

As an aside, I'm looking for help with cr.opensolaris.org.  This is a great opportunity for someone to step up and help out with an important part of our community infrastructure.  Send me mail.

You can check out the results of my hacking on cr.opensolaris.org.  Or you can subscribe to the feed.  If you want to opt-out of publishing reviews, you can create a file called "opt-out" in the same directory as your webrev's index.html file.  Or you can create a file called "opt-out" in your home directory, if you'd like to opt out of all reviews.

Implementation Notes 

This was an interesting learning experience for me, since I had to learn a lot about ATOM in the process.  I also learned the XSLT language along the way as well, and how to process HTML using python.  All in all, I'd say this project took about 20 hours of effort, and resulted in about 500 lines of python code.  The most difficult problems to solve were:

• I wanted the feed to include some meaningful information about the codereview.  If you subscribe to the feed using your favorite reader, you'll see that a portion of the "index.html" file from each webrev is included.  This is done using a somewhat tricky piece of python code.  In retrospect, using XSL for this might have been a better choice, although I've found that people have a tendency to introduce non-standard HTML artifacts into their webrev index.html files, and I don't know how well XSL would cope with that.
  
  
• ATOM has some rules about generating unique and lasting IDs for things-- this is the contents of the <id> tag in the ATOM specification.  I found a lot of valuable information on dive-into-mark.  For cr.opensolaris.org, this was complicated by the fact that the user might log in and move their codereview around, or might copy one review over another.  In the end, I solved this by remembering the <id> tag in a dot-file which rides along with the codereview.  A cronjob roves around the filesystem looking for new reviews, and adds the special tag-file.  By storing the original <id> tag value, and looking at the modtime of the index.html file, I can correctly compute both the value of the <id> and <updated> fields for each entry.  If a user deletes a codereview, the dot-file will go away with it.
  
  
• Once I had an ATOM feed I needed to transform it back into HTML for display on the home page.  The only problem was that there aren't a lot of good examples of this on the web-- many of the ATOM-to-HTML conversions only work with ATOM 0.3, not the 1.0 specification, and I didn't know the first thing about XPATH or XSL.  In the end, I only needed 25 lines or so of XSLT code.
  

Future Work 

I think of the current implementation as a "1.0"-- it'll probably last us pretty well for a while.  One thing I'd like to research for a future revision is actually placing the entries into a lightweight blog engine, and letting it do the rest of the work: Using an excellent list from Social Desire I took a quick look at Blosxom, Flatpress, Nanoblogger, and some others.

(2008-03-24 14:22:56.0) Permalink Comments [3]
Tags: code codereview cr.opensolaris.org opensolaris review
Trackback: http://blogs.sun.com/dp/entry/cr_opensolaris_org_gets_an

Some days, when it's cold and you're not feeling very motivated (like me, today), it's nice to do a zpool scrub on the machines you manage, and then once it's done:

$ zpool status
  pool: aux
 state: ONLINE
 scrub: scrub completed with 0 errors on Tue Jan 29 15:52:38 2008
config:

        NAME          STATE     READ WRITE CKSUM
        aux           ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c1t0d0s7  ONLINE       0     0     0
            c1t1d0s7  ONLINE       0     0     0

errors: No known data errors

And then relax, knowing that your data is safe.
(2008-01-29 17:23:44.0) Permalink Comments [2]
Tags: solaris zfs
Trackback: http://blogs.sun.com/dp/entry/the_joy_of_zpool_scrub

Hal Stern invited Joost and I to sit down for a chat about the Solaris 8 Migration Assistant for an episode of his podcast Innovating@Sun.  This was my first podcast experience and it was a lot more fun than I had expected.   Check it out here, or you can download the MP3 audio directly.

(2007-12-04 18:14:56.0) Permalink Comments [1]
Tags: containers solaris solaris8 virtualization zones
Trackback: http://blogs.sun.com/dp/entry/podcast_on_etude

Recently I've been thinking about, learning about, and contributing to IPS, the Image Packaging System, a next generation package management solution project which is happening in the OpenSolaris community.  IPS happens to also be the packaging system project Indiana has elected to use.  Stephen has written extensively about his thoughts on his blog.  And Bart has too.  IPS subsumes a lot of existing functionality which appears in various parts of the system today.  But a lot of people seem to be willing to look at it only as a package manager in the sense that "pkgadd" is a package manager.

My problem with this is that "pkgadd" is only a small part of a larger problem.  So, to explain that, I want to distill a series of email posts I made to pkg-discuss last month into a coherent blog entry, since I've referred back to them a couple of times.

My feelings on this topic are pretty nicely summarized by an article by Peter J. Denning which recently appeared in Communications of ACM, entitled "Mastering the Mess."  The whole article is instructive, but see in particular: "Signs of Mess."

If one accepts Dr. Denning's "mess" framework, then the next question is whether we are in what he dubs, "a mess."  I personally think the answer is "yes."   In no particular order (apologies to anything I left out), as a community, we have:

 

• SVR4 package creation tools
  
• SVR4 package deployment tools
• Sun's patch creation tools
• Sun's patch application and inventory tools (patchadd, showrev -p)
• PCA (Patch Check Advanced, a nice open source tool I use)
  
• Solaris Patch Manager (smpatch)
• pfinstall
  
• Live Upgrade
• flash archive creation and deployment tools
  
• graphical install (old and dwarf caiman, etc)
• ttinstall
  
• Jumpstart
  
• virt-install (from xVM)
• zones install
• zones attach/detach logic (which knows how to parse various patch and packaging databases)
• So-called "toxic" patching for zones
• Zones support for live upgrade (zulu)
• BFU/ACR (update part of the system, but violates package metadata)
• IDR (patches the system, but renders system subsequently unpatchable until IDR is removed and a "real patch" is applied)
• Solaris Product Registry (I've never really understood what this was for, but you can try it via prodreg(1))
• Service Tags -- a layer which adds "software RFID tags" in a sense: UUIDs backed by a Sun-maintained ontology; helps to inventory what is on your system.
  
• pkg-get
• Network Repositories (like Blastwave)
• DVD media & CD media construction tools (several of these, I think)
• Various other unbundled products which promise to ease "patching pain"
• Various system minimization tools
• Layered inventory management tools
  
• Numerous hand-rolled and home-grown solutions built on some or all of the above.                                            
  

Some parts of the mess represent great (from the perspective of the those caught up in the mess) technologies which people have spent a lot of time and effort building.  But a lot of the above represent accreted layers with duplicated functionality.  In some cases, the various layers interact in complex and subtle, and perhaps interface-violating ways. To people outside of the mess (i.e. new users we would like to entice) the mess looks bizarre, and terrible.  Another sign of a "big mess":  In several cases, huge engineering efforts have resulting in only modest improvements.  In some cases, huge engineering efforts have been total failures: Sun attempted a rewrite of the SVR4 packaging system in the early part of this decade, the project basically failed.

It's easy to look at the above list and feel a sense of hopelessness-- how will we *ever* improve upon this situation?  Will people keep creating new and different tools which add more layers? 

I'll cite a second source which has helped guide my thinking on this topic: Jeff Bonwick.  Jeff spent years relentlessly seeking out and blowing up duplicated and broken kernel functionality, and then took on the storage stack.  The result was ZFS, which was recently labelled "a rampant layering violation" by a detractor.  Jeff responded this way.  In particular, Jeff said:

"We found that by refactoring the problem a bit -- that is, changing           
where the boundaries are between layers -- we could make the whole thing
much simpler."

Which to me summarizes my thinking about what the *opportunity* is here: to rethink the layers and to merge and unmerge them to come to a more complete, efficient, modern
solution.

IPS is heading in this direction: Packaging, patching, upgrade, live upgrade, the mechanisms for Software Delivery, the toolset for delivering packages/patches, and the software-enforced policy decisions seem to be condensing here into a coherent entity-- which means we'll have many fewer layers.  And because the system will be fast, lightweight, redistributable and shared, we should also be able to discard artifacts such as BFU and ACR (in other words, OpenSolaris developers will use the same tools our customers use to update systems).  The huge amount of code which handles zones patch and packaging should be greatly reduced.  Package dependencies will be far more accurate and minimization will be easier, and diskless client support should be far more robust.

What I see with Caiman, IPS and Distro Constructor is the opportunity to do for software delivery and update to OpenSolaris systems what ZFS did for storage management.  I do not think we have all the answers just yet, but I think we can get there.

(2007-11-14 13:47:08.0) Permalink Comments [4]
Trackback: http://blogs.sun.com/dp/entry/a_big_mess

I'm very happy to announce that the Solaris 8 Migration Assistant 1.0 (also known as Project Etude) has shipped!  The product is now officially available from Sun.  Some key links:

• You can download and install the product (a free 90 day eval license is provided)
• You can browse the documentation online
• You can read the FAQ
• You can learn more from my previous blog entries about Etude (here, and here)
• You can contact your local Sun representative to learn more about this technology

In a nutshell, the product provides a migration solution from Solaris 8 to Solaris 10 by creating a bridge between the two operating systems.  You can perform P2V (physical-to-virtual) conversions of existing Solaris 8 systems, and drop those into Solaris 8 containers running on your Solaris 10 host.

Above all, I want to take another chance to thank the many people who worked extremely hard for the past eight months to make this project a reality.  It was sprint from start to finish, which is certainly tough on everyone involved.  But I was amazed and pleased that almost universally, people helped us out with dedication and a good sense of humor.  Thank you very much.

(2007-10-22 14:11:37.0) Permalink Comments [5]
Tags: containers etude solaris solaris8 virtualization zones
Trackback: http://blogs.sun.com/dp/entry/solaris_8_migration_assistant_1

On Thursday I posted this announcement to opensolaris-announce, which notes that I have taken cr.opensolaris.org out of beta status. Please take a look, use, and enjoy...

I am pleased to announce that cr.opensolaris.org, the OpenSolaris
Code Review site, is now officially part of the opensolaris.org
infrastructure. I encourage everyone in the community to use it.

In the March 2007 community priorities poll, the community declared:

...
#3 Deploy a public code review facility on opensolaris.org
...

cr.opensolaris.org was designed to meet that goal. It has been in Beta
test for some time, and after some final tweaking[1] it is now ready for
production.

You will need an SSH key linked to your account in order to use it.
For more information on SSH keys, see
http://opensolaris.org/os/project/website/ssh_instructions/.

Once you have a registered key, see http://cr.opensolaris.org for
information about how to gain access to this system. We request
that users review the terms of service before using it. Problems can be
reported to website-discuss at opensolaris dot org.

Finally, if you would like to help out with the coding/maintenance of
this site, please visit the site and read the "Call for Help" section.

Thanks

Dan Price

[1]: Specifically, concerns about who may access the system have been
resolved.

(2007-10-13 09:35:35.0) Permalink Comments [3]
Tags: code codereview cr.opensolaris.org opensolaris review
Trackback: http://blogs.sun.com/dp/entry/cr_opensolaris_org_now_live

I was lucky enough to get to attend CEC (Sun's Customer Engineering Conference) in Las Vegas, although not lucky enough to win anything at the casino.  So now, I'm sitting in the CEC System Launch session, and John Fowler is launching the new T5120 and T5220 systems.  Thankfully there is ample wifi here in the hall.

The best news for me is that John just announced the product I've been working on, the Solaris 8 Migration Assistant (or Project Etude) and showed how it can help with migration and consolidation activities.  A FAQ has been posted over here.  That's not to say that you can download and use it now.  But very soon!  I think that these new systems in combination with the Solaris 8 Migration Assistant will make a very tempting combination for our customers who are still running Solaris 8 on older hardware.  You can upgrade and reduce your service costs, rack space, cooling, power costs, and get greater performance and bandwidth.

(2007-10-09 11:14:23.0) Permalink Comments [5]
Trackback: http://blogs.sun.com/dp/entry/solaris_8_migration_assistant_etude

I have a home server which I built myself.  I also occasionally use it as a desktop system, especially when I have a long computing session planned, when my laptop would tend to get uncomfortable.  Unfortunately, I've been unable to get Solaris to drive the audio.  I think this is bug 6518184 but despite some hacking with /etc/driver_aliases I couldn't get the onboard audio device to attach.  While I need to get my home machine updated to the last SXDE release in order to really tackle this properly, I found myself really wanting working audio, now.  I happened to stop in at my friendly neighborhood computer shop, and noticed a USB audio gadget for $25 (I actually snagged an open box model for $20), the Vantec NBA-100U. It works like a charm in Solaris thanks to its excellent USB audio support.  Here is what it looks like from 'cfgadm -av':

usb0/2                         connected    configured   ok         Mfg: <undef>  Product: USB Audio  NConfigs: 1  Config: 0  <no cfg str descr>

It's pretty bare bones-- you can see that Vantec didn't even bother to set the Manufacturer string!  Kwality.  Once I plugged it into my USB port and into some cheap speakers, I simply had to start up rhythmbox and everything worked like a charm. The audio quality seems fine to me.  While the device supports 5.1 audio, it does so only under Windows.  Stereo is fine for me.  I should also note that the volume up and down buttons are non-functional both on Solaris and on Macs.  This is no big deal for me as the thing is buried under my desk, and my speakers and Solaris both have volume control.

I realize that cheaper USB audio gadgets can be had, but this one should be easy to find online and seems to work reliably.  It's really nice when it all "just works."

(2007-10-03 00:56:44.0) Permalink Comments [3]
Trackback: http://blogs.sun.com/dp/entry/success_with_usb_audio

The whole Etude engineering team (except, unfortunately, for Penny) gathered in the Bay Area last week.  We made a ton of progress and we're on our final round of bug fixes.  It has been fun (if a bit nerve wracking) to watch the bug counts drop day by day.

One problem which has been challenging with this project is that we have a number of differently delivered software parts, all of which must undergo some change:

• The solaris8 brand itself is a piece of software which bridges the gap between Solaris 8 and Solaris 10.  This is something you must add to an Solaris 10 8/07 (also called S10U4) system.  When it is finished, it will be delivered as two packages, SUNWs8brandu and SUNWs8brandr, plus an optional "demo" package.
  
• We've got a very few Solaris 8 patches which we require (currently I think there are 6 of them).  Some of these (for example, a fix to the linker, and a fix to ptree(1)) we had to engineer ourselves. And some have been available for a long time and are probably already patched onto most S8 systems out there.  All of these are (or will be) available via the normal patch mechanisms.
  
• We needed to add some enhancements to Solaris 10 in order for BrandZ to work solidly on SPARC systems.  While these changes will be automatically included in the next update of Solaris 10, for Solaris 10 8/07 you need to add a patch-- the kernel jumbo patch, in fact (as I mentioned before, this patch is not out just yet).
  

For our Beta release, we were able to supply workarounds for some of these issues, but for our official release, we need every 't' crossed, and every 'i' dotted. So last week we finally had all of those pieces available (internally) in at least a preliminary form.  Everyone has been busy testing the whole works.  For example, I've done a dry run on a T1000, which looks like this:

• Install S10 8/07 onto the system (or into an LDOM (logical domain) on the system)
  
• Bring system to single user mode
  
• Add kernel patch using patchadd
• Reboot system (or LDOM)
  
• Add SUNWs8brandr and SUNWs8brandu packages to the system
• Configure a Solaris 8 container and install it from an existing system archive
• This will auto-apply any required Solaris 8 patches to the system
• Boot S8 zone, and enjoy!
  

It's nice to see the pieces coming together...

(2007-09-26 11:27:39.0) Permalink Comments [7]
Tags: brandz etude solaris solaris10
Trackback: http://blogs.sun.com/dp/entry/etude_progress_update

Well, it has been a while since I last wrote anything here.  I have been working on a team developing a new project, which we named Etude.  Marc Hamilton, VP of Solaris Marketing, has written about it here.

[As an aside, it's weird to have a code name you selected cross the lips of senior executives several months later] 

In a nutshell, we've built a Solaris Container (or Zone) which is capable of running the Solaris 8 user environment.  We have also created a capability to perform P2V (or Physical-to-Virtual) transformation of existing Solaris 8 systems into containers running on a Solaris 10 host.  This is an enabler for rapid migration of legacy Solaris 8 environments onto modern, environmentally friendly, cost effective hardware.  And onto Solaris 10.  The idea is to break up the upgrade tasks into chunks, allowing the hardware and OS to be upgraded, while continuing to run legacy environments.  Next, the legacy environments can be used until they are retired, or redeployed into Solaris 10 containers, or into logical domains.

I will write more about the why and the how of this project in a future blog entry.  (And Marc does a good job of explaining some of the why in his blog, so go there for more background).  But for now, I want to expand upon the what.  The notion of a Solaris 8 container was not a new one when we began to look at this problem early this year.  But with the completion of the BrandZ project, we had the tools in hand to make a serious attempt to realize this idea.  BrandZ was originally developed so that we could have a "Linux Zone" but the core "brand" framework is really very flexible (and is now more so, thanks to our work).  It allows the development of a variety of OS personalities atop Solaris 10.

So who built Etude? I'm very lucky to be leading a group of seasoned and incredibly talented engineers: Bill, Ed, Jerry, and Steve (no blog), and Penny on documentation.  We worked at something of a breakneck pace to assemble a prototype, which we had in hand by late April. Since then, we have worked to convert the prototype into a production quality offering.  I'll try to say more about that later.  Along the way, we've had a lot of help from many corners of the company-- people too numerous to list.  I especially want to thank Bill Franklin, Jerri-Ann, Joost, Susan, Allan, Richard, Tim and Liane.

Ok, so I'm anxious to show off our creation. First, let's archive a Solaris 8 system using the Flash Archiving tools. If your S8 system is patched up to date, you already have these tools installed. Alternatively, you could use CPIO or ufsdump or some other tool to create a suitable archive:

s8-system # uname -a
SunOS s8-system 5.8 Generic_108528-29 sun4u sparc SUNW,UltraAX-i2
s8-system # flarcreate -S -n s8-system /net/s10system/export/s8-system.flar
Determining which filesystems will be included in the archive...
Creating the archive...
Archive creation complete.
s8-system #

[Note to our beta customers!  In the beta version of Etude, support for Flash Archives is not present, so if you use this blog entry as a substitute for reading the documentation, you will be disappointed.  Please ensure that you carefully read the supplied instructions] 

In the above example, I've simply used NFS to place the flash archive onto my Solaris 10 system, but you could use any method for moving files around. Now, we'll head over to the Solaris 10 system and create a container suitable for use as a Solaris 8 environment...

s10-system # zonecfg -z s8-system
s8-system: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:s8-system> create -t SUNWsolaris8
zonecfg:s8-system> set zonepath=/aux/zones/s8-system
zonecfg:s8-system> add net
zonecfg:s8-system:net> set address=10.6.62.226/24
zonecfg:s8-system:net> set physical=e1000g0
zonecfg:s8-system:net> end
zonecfg:s8-system> add dedicated-cpu
zonecfg:s8-system:dedicated-cpu> set ncpus=2
zonecfg:s8-system:dedicated-cpu> end
zonecfg:s8-system> commit
zonecfg:s8-system> exit

s10-system #
s10-system # zoneadm list -vc
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   - s8-system        configured /aux/zones/s8-system           solaris8 shared

The last part (setting ncpus=2) is not strictly necessary, but is a good example of how easy it is to allocate CPU resources to containers starting in Solaris 10 8/2007. Jerry (who led that work) and Jeff Victor have written more about this capability here and here.  (By the way, Solaris 10, 8/07 was launched yesterday, and includes BrandZ and many other enhancements to the containers infrastructure.)

Now that we've configured the zone, we need to install it.  We'll use the flash archive we made to do so:

s10-system # zoneadm -z s8-system install -a /aux/flar/s8-system.flar
      Log File: /var/tmp/s8-system.install.104490.log
        Source: /aux/flar/s8-system.flar
    Installing: This may take several minutes...
Postprocessing: This may take several minutes...

        Result: Installation completed successfully.
      Log File: /aux/zones/s8-system/root/var/log/s8-system.install.104490.log
s10-system # 

That's it! We've now installed a Solaris 8 container! Let's boot it up, and log onto the console, and see what happens:

s10-system # zoneadm -z s8-system boot; zlogin -C s8-system
[Connected to zone 's8-system' console]

SunOS Release 5.8 Version Generic_Virtual 64-bit
Copyright 1983-2000 Sun Microsystems, Inc.  All rights reserved

Hostname: s8-system
The system is coming up.  Please wait.
NIS domainname is mpklab.sfbay.sun.com
starting rpc services: rpcbind keyserv ypbind done.
syslog service starting.
Print services started.
The system is ready.

s8-system console login: root
Password: 
Sep  5 17:55:52 s8-system login: ROOT LOGIN /dev/console
Last login: Wed Sep  5 13:11:37 on console
Sun Microsystems Inc.   SunOS 5.8       Generic Patch   February 2004
s8-system # uname -a
SunOS s8-system 5.8 Generic_Virtual sun4v sparc SUNW,Sun-Fire-T200
s8-system # psrinfo
0       on-line   since 08/29/07 13:32:21
1       on-line   since 08/29/07 13:32:23

We could have also performed a sys-unconfig(1m) on the Solaris 8 image during the container installation (by passing -u to the installer). In that case, we would have been asked to answer the usual system identity questions. This zone can be cloned, moved around, renamed, attached/detached and manipulated like any other. You can even install it atop a ZFS filesystem, and from the global zone, use DTrace against the applications running inside of it.

Most importantly, you can run real workloads. Building on the Solaris Application Binary Compatibility Guarantee, we have done the difficult work to make sure that your applications will work successfully inside of these containers. This includes software such as databases, application servers, Java programs, web servers, and more. We've also utilized the amazing array of test suites we have available in-house.  You can even do software development inside of Solaris 8 Containers, building binaries which will run on any Solaris 8 (and 9, and 10) systems.

You can also patch these containers using the same tools you use to patch Solaris 8 (and using the same patches). We've even pulled down hundreds of Blastwave packages to test gnome, KDE, and lots of other applications available there. You can run your favorite ancient desktop environment: Solaris 8 was the last version of Solaris to include OpenWindows. So here's the obligatory screenshot from the wayback machine: Netscape 4.x, Java 1.3 and some other miscellaneous stuff all running atop the OpenWindows environment.  Running on emulated Solaris 8, on Solaris 10, on a T2000. A weird blast from the past mixed up with the present day.  (It's interesting to think that today's whizzy desktop applications will in a few years look just as antiquated as OpenWindows and Netscape 4.x do today).  Click the image to zoom in.

 

That's all I have time for tonight.

If you're interested in hearing more about this technology, talk to your local Sun Representative. Or if that fails for any reason, send me an email (my-firstname dot my-lastname @sun.com will do the trick) and I'll try to hook you up with someone helpful (please put "Etude" in the subject line).

(2007-09-05 21:11:14.0) Permalink Comments [14]
Tags: containers etude solaris zones
Trackback: http://blogs.sun.com/dp/entry/project_etude_revealed