Sun Microsystems releases VirtualBox 2.1.0

On 2008, December 17, Sun Microsystems has released version 2.1.0 of its VirtualBox software for desktop virtualization. Version 2.1.0 is a major update which introduces the following new features:

• Support for hardware virtualization (VT-x and AMD-V) on Mac OS X hosts
• Support for 64-bit guests on 32-bit host operating systems (experimental; see user manual, chapter 1.6, 64-bit guests, page 16)
• Added support for Intel Nehalem virtualization enhancements (EPT and VPID; see user manual, chapter 1.2, Software vs. hardware virtualization (VT-x and AMD-V), page 10))
• Experimental 3D acceleration via OpenGL (see user manual, chapter 4.8, Hardware 3D acceleration (OpenGL), page 66)
• Experimental LsiLogic and BusLogic SCSI controllers (see user manual, chapter 5.1, Hard disk controllers: IDE, SATA (AHCI), SCSI, page 70)
• Full VMDK/VHD support including snapshots (see user manual, chapter 5.2, Disk image files (VDI, VMDK, VHD), page 72)
• New NAT engine with significantly better performance, reliability and ICMP echo (ping) support (bugs #1046, #2438, #2223, #1247)
• New Host Interface Networking implementations for Windows and Linux hosts with easier setup (replaces TUN/TAP on Linux and manual bridging on Windows)

The list of fixes is extensive, too:

• VMM: significant performance improvements for VT-x (real mode execution)
• VMM: support for hardware breakpoints (VT-x and AMD-V only; bug #477)
• VMM: VGA performance improvements for VT-x and AMD-V
• VMM: Solaris and OpenSolaris guest performance improvements for AMD-V (Barcelona family CPUs only)
• VMM: fixed guru meditation while running the Dr. Web virus scanner (software virtualization only; bug #1439)
• VMM: deactivate VT-x and AMD-V when the host machine goes into suspend mode; reactivate when the host machine resumes (Windows, Mac OS X & Linux hosts; bug #1660)
• VMM: fixed guest hangs when restoring VT-x or AMD-V saved states/snapshots
• VMM: fixed guru meditation when executing a one byte debug instruction (VT-x only; bug #2617)
• VMM: fixed guru meditation for PAE guests on non-PAE hosts (VT-x)
• VMM: disallow mixing of software and hardware virtualization execution in general (bug #2404)
• VMM: fixed black screen when booting OS/2 1.x (AMD-V only)
• GUI: pause running VMs when the host machine goes into suspend mode (Windows & Mac OS X hosts)
• GUI: resume previously paused VMs when the host machine resumes after suspend (Windows & Mac OS X hosts)
• GUI: save the state of running or paused VMs when the host machine’s battery reaches critical level (Windows hosts)
• GUI: properly restore the position of the selector window when running on the compiz window manager
• GUI: properly restore the VM in seamless mode (2.0 regression)
• GUI: warn user about non optimal memory settings
• GUI: structure operating system list according to family and version for improved usability
• GUI: predefined settings for QNX guests
• IDE: improved ATAPI passthrough support
• Networking: added support for up to 8 Ethernet adapters per VM
• Networking: fixed issue where a VM could lose connectivity after a reboot
• iSCSI: allow snapshot/diff creation using local VDI file
• iSCSI: improved interoperability with iSCSI targets
• Graphics: fixed handling of a guest video memory which is not a power of two (bug #2724)
• VBoxManage: fixed bug which prevented setting up the serial port for direct device access.
• VBoxManage: added support for VMDK and VHD image creation
• VBoxManage: added support for image conversion (VDI/VMDK/VHD/RAW)
• Solaris hosts: added IPv6 support between host and guest when using host interface networking
• Mac OS X hosts: added ACPI host power status reporting
• API: redesigned storage model with better generalization
• API: allow attaching a hard disk to more than one VM at a time
• API: added methods to return network configuration information of the host system
• Shared Folders: performance and stability fixes for Windows guests (Microsoft Office Applications)

The original changelog can be read here.

Enjoy!

Setting up Subversion on Solaris 10 as an inetd service

Some posts ago I described how I set up Subversion on Solaris 10 in daemon mode and managed via SMF. It exists another way to invoke svnserve: it can be run via inetd. svnserve, when invoked with the -i|--inetd option will use stdin and stdout to communicate to a Subversion client: this is the expected behavior of an inetd-based service.

These instructions are valid for an UNIX system with an inetd implementation. Registration of this configuration as an SMF service is Solaris 10 specific.

Configuring /etc/services

The first thing to do is checking if /etc/services defines the Subversion service. IANA has reserved port 3690 for the Subversion service, so that /etc/services should contain:

svn 3690/tcp
svn 3690/udp

Please note that svn is just a service identifier which will be used during inetd configuration.

Setting up the inetd daemon

The standard UNIX inetd daemon accepts configuration on a file usually called /etc/inet/inetd.conf or /etc/inetd.conf for compatibility with BSD. In the case of Solaris 10, that file is not used anymore and inetd-based services are managed by SMF, too. There indeed is a /etc/inetd.conf file if you check your file system: it's used as a configuration file to be fed as input of the inetconv utility during the configuration of a service. inetconv can be invoked with the -i option to use an alternate file, which is what I usually do. Then, touch a new empty file or make a copy of /etc/inetd.conf which will be used later to configure the SMF service.

inetd.conf syntax

The expected syntax for /etc/inetd.conf file *or the file you'll feed inetconv with) is the following (see the man page for more details):

service-name endpoint-type protocol wait-status uid server-program server-arguments

• service-name: the name specified in the /etc/services file.
• endpoint-type: the type of the endpoint, which can be stream, dgram, raw, seqpacket, tli.
  
• protocol: a valid protocol entry in the /etc/inet/protocols file. Additionally, tcp6 and udp6 may also be used. In the case of RPC services, it's a string of the type rpc/* or rpc/..., where ... is a combination of nettypes and/or netids.
  
• wait-status: this field may assume the values wait or nowait. Basically, it instructs inetd whether to pass over the listening socket to the service process and waiting for it to finish before resuming listening.
  
• uid: the user id under which the service will run
  
• server-program: the pathname of the server process executable or an internal name if inetd itself will provide this service.
  
• server-arguments: the entire command line arguments for the service process, including the service process name itself (argument 0)
  

Subversion entry

The syntax to use for svnserve is the following:

svn stream tcp nowait svnuser /opt/csw/bin/svnserve svnserve -i -r /home/svnuser/svnrepos

• I previously set up a standard user, svnuser, under which the Subversion service will run.
  
• In this case I'm using the Subversion package installed from Blastwave which installs into /opt/csw/bin.
• The repositories served by this instance are located into directory /home/svnuser/svnrepos.

Setting up the Subversion user

Creating the user

Subversion server process will run as a regular user called svnuser. This user is a basic user created with:

# useradd -d /export/home/svnuser -m -k /etc/skel -s /bin/bash svnserve
# passwd svnuser
[...]

Assuming that home automounting under /home is configured, I then modify the user with:

# usermod -d /home/svnuser svnuser

In my case, this user was created in the LDAP directory which I manage with Sun Java System Directory Server Enterprise Edition but basically the result is equivalent to running the above mentioned commands.

Creating a default user project (Solaris 10 specific)

I also created an user project for this user, called user.svnuser, so that processes launched after svnuser login will be associated with its project. The project I created just caps the CPU associated with its processes:

# projadd -K "project.cpu-cap=(privileged,50,deny)" user.svnserve

Setting up the SMF service (Solaris 10 specific)

After setting up inetd, under Solaris 10 we have to configure the described service with inetconv. inetconv it's an utility which reads files containing inetd.conf-like records and maps them to auto-generated SMF services. If the file we've generated it's called svn.conf, we have to run the following command:

# inetconv -i svn.conf

and a new SMF service description will be generated, imported and enabled.

Conclusion

Setting up inetd based services it's even easier with Solaris 10. Moreover, the powerful SMF framework will allow the sysadmin to manage and observe every service and enjoy the advantages of SMF. The only problem not (yet) addressed by this blog post is that a nowait inetd service is fork()-ed and exec()-ed by inetd and as Solaris 10 documentation states, during the fork() system call the process and task controls are inherited. This has the effect that even if svnserve is fork()-ed and then run under the svnuser account, the project.cpu-cap entry is having no effect. To discover how to configure an execution method of an SMF-managed service to run into a Solaris 10 project, read this post.

Next steps

You can now:

• Read this post about how you can set up Solaris projects or zones to control resource usage.
• Read this post about setting up SSH access to Subversion repositories.
• Read this post about how to set up Subversion post-commit hooks.
• Read this post about filtering Subversion commit using a post-commit hook.

Caught in a winter storm at El Espinar

It was a long time I was not caught by surprise in a winter storm. The last time I remember I saw something similar to that was in Italy, I believe during the winter of 2001.

I was taking my girlfriend home from Las Rozas (Madrid, Spain) when it started to heavily snow above the A6 motorway. In a questions of minutes (at an average speed of 80 km/h) the landscape was absolutely white and the snow flakes density in the air was so high that I initially confused it with mist.

We reached without many problems El Espinar but once there, I was seeing no way back. I was driving an Alfa Romeo GT Q2 with bare pneumatics and we covered the last slope before reaching her house crossing our fingers. It was not even 21 o'clock. I stayed there until 23.00 hoping the situation changed but it was constantly worsening instead. I couldn't wait any longer: I already spent a night in a car during a winter storm and I preferred not to do it again. The last cigarette and the last kiss. I took my car and went away.

Sort of a driver's nightmare. The landscape was incredibly beautiful, the sky was gray with a sort of luminescence, probably due to the full moon, and it was throwing sinister reflections on the woods surrounding El Alto del León; the atmosphere was frightening and my car was the only one on the highway.

I will remember this for a long time.

Sun drastically reduced the availability of x64 workstations

I just realized that, after abandoning the line of SPARC workstations, another two Sun Microsystems' workstations have reached their end of life: Sun Ultra 20 M2 and Sun Ultra 40 AMD-base workstations aren't on sale any longer. The only workstation left (whichever its CPU architecture) is the Sun Ultra 24. I have bought some of them and, despite some Solaris 10 bug, I'm happy with these Intel Core2 {duo, quad}-based machines. I was going to order another set of Ultra 20 M2 when I realized of their departure. I think I'll miss those workstations: AMD-based, two NICs by default and a maximum number of 8 disk drives, against the 4 allowed on the Ultra 24, whose default configuration is more like a powerful PC than a workstation.

Upgrading Sun Java System Directory Server Enterprise Edition to version 6.3

Introduction

As part of my network infrastructure I also deployed an instance of Sun Java System Directory Server Enterprise Edition (JSDSEE from now on). I chose to download and install it with the Sun Java Enterprise System (JES from now on), which at the time of writing has reached version 5 update 1, which ships JSDSEE 6.2.

Installation of this and other products with the JES installer went smooth on my Solaris 10 update 5 instances and the services were deployed, configured and up and running in a question of minutes.

Some weeks ago we had an abrupt server shutdown the same day I was adding some entries in the LDAP server. When the server went up it was no big surprise to me discovering that the LDAP database was corrupted and the only options I had was restoring from a backup, which I had obviously done. Again, the service was restored in a matter of minutes.

However, I discovered by chance that JSDSEE 6.2 is affected by a bug that, in certain conditions, may result in data loss and database corruption. The bug report can be examined at Sun Solve website at this address: JSDSEE bug #6642430. The bug has been resolved but it implies upgrading JSDSEE from version 6.2 to version 6.3.

Getting the software

When it comes to getting the software, you are presented these options:

• Sun Java Enterprise System distribution
  
• native packages distribution
  
• zip distribution

The JES installer installs its products with native packages and I usually prefer to use this method rather than install zip distributions and carefully tracking down the details about every software I installed. In this case is that the native package distribution is a patch to apply to a previous JSDSEE installation.

Differences between the distributions

The differences between the distributions are described in the document Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide. It's not obvious, because the documents I read first, Sun Java System Directory Server Enterprise Edition 6.3 Release notes and Sun Java System Directory Server Enterprise Edition 6.3 Installation guide, tell nothing about this.

Java Enterprise System distribution

Basically, the JES installer is a native package distribution, but it still delivers just JSDSEE v. 6.2, and you can only rely on a patch to upgrade JSDSEE to v. 6.3. The JES installer, also, does not provide the Directory Server Resource Kit, which is provided by the zip distribution. The JES installer is a GUI tool which facilitates the installation of the components delivered with JES and it also facilitates the shared components used by the products in the suite. The JES installer must be run as root because the products are installed as native packages.

Native patches

The native patches must be run as root, too, and let you upgrade your existing JSDSEE installation to version 6.3. As I'll tell in the following sections, these installation method is not supported on Solaris Express or OpenSolaris.

Zip distribution

The zip distribution is a non-root self-contained distribution which can installed by anyone. Multiple version of the product can then be installed at the same time. The drawbacks of this kind of distribution is that the system administrator is responsible of having these services start at system boot and that whoever installs them must keep a detailed log of every installed product.

Test run on Solaris Express Community Edition

Before upgrading a production server, I always test the installation on another machine. Unfortunately I had no such machine at hand so I decided to test the installation on Solaris Express Community Edition (SXCE from now on) build 103. I'm using SXCE because the JES installer was not running properly on OpenSolaris 2008.05 so I switched some development machines to SXCE to be able to use these kind of Sun distributions.

The JES installer went smooth on SXCE and I also replicated the LDAP database on the test machine. Unfortunately, when it came to run the patches, I was caught in a sort of patch hell because I found no way to install the required patches on it without having patchadd complaining about packages' versions or dependent patches. After losing and entire night trying, I decided to switch to Solaris 10.

Patching JSDSEE 6.2 on Solaris 10

This time, everything went absolutely smooth. I just followed the recommendations on the Sun Java System Directory Server Enterprise Edition 6.3 Installation guide and I just ran the following commands in this order (be aware that these patch numbers are relative to Solaris 10 x86/AMD64). The list of patches is available here.

Stopping the services

After patching, all the services must be shut down. First I stopped the Directory Server Control Center

# dsadm stop /var/opt/SUNWdsee/dscc6/dcc/ads

the I stopped the JSDSEE instance I previously registered with SMF. This step depends on your installation.

Upgrading shared components

I installed the following patches taking care of following the special instructions included with them (if your system is not Solaris 10 AMD64 please check this):

• 119811-05
• 125953-18
• 119044-03
• 123896-05
• 125446-12
• 119214-17 (be aware that this patch number depends on the version of some system packages. Check documentation before installing)

Installing the patches to version 6.3

The patches to install on Solaris 10 AMD64 are these (be aware that the localization patch must be installed before the JSDSEE v. 6.3 patch):

• 125938-06 (localization patch)
• 125278-07

Conclusion

After installing these patches and restarting the JSDSEE services, everything was up and running. Since now on, I'll always have a Solaris 10 installation to test these kind of setups because it's not the first time I have problems with Sun packages on SXCE or OpenSolaris.