Accessing ZFS Snapshots From Windows With "Previous Versions"

ZFS Snapshots

Solaris' ZFS snapshots are a great tool that allows us to instantly create a block level snapshot of a ZFS file system. ZFS uses copy-on-write semantics: newly written data is stored on new blocks while blocks containing the older data are retained (when referenced by, for example, a snapshot.) Since, at snapshot creation, data has already been allocated, both snapshot creation time and snapshot required storage (additional to referenced blocks) are almost negligible. Snapshots can be sent (to a file, over the network, etc.) and received on a destination host (as a file or as a ZFS file system.)

Using ZFS snapshots on Solaris and OpenSolaris is dead easy and incredibly flexible: not only you can snapshot a ZFS file systems for Solaris' own use. Since ZFS file systems are easily shared with many protocols such as NFS, CIFS or iSCSI, you can for example take a snapshot of a ZFS volume used as a Mac OS X Time Machine disk (what I call a two-dimensions time machine), or of a file systems shared with CIFS with Windows clients.

Where Are The Snapshots?

Solaris users probably know that snapshot can be accessed using the special .zfs directory on a ZFS file system. But what if you're accessing this filesystems remotely, for example via CIFS? A first approach might be making .zfs directories visible by setting their snapdir property accordingly:

# zfs set snapdir=visible your/zfs/file/system

Although this method perfectly works and may even seems natural to Solaris users, it might seem to lack the required amount of "user friendliness" required by the typical Windows user. Fortunately, thanks to CIFS, there's another solution which is just as easy and that perfectly integrates with the Windows user experience.

Shadow Copy and the Previous Versions Shell Extension

Microsoft introduced a technology called Shadow Copy (a.k.a. Volume Snapshot Service) back in Windows XP SP 2 and Windows Server 2003. Shadow copy is similar to ZFS snapshots in that it takes block-level snapshots of a running file system (although much more limited.) Microsoft also introduced a shell extension, called Previous Versions, that let the user browse through the previous versions of a file that's been shadow copied. With this extension, a new tab in your Windows Explorer's File Properties window, you can browse and restore a previous version of a modified or deleted file. It seems natural, then, to use this extensions to browse through the ZFS snapshots too.

CIFS

That's exactly what the CIFS guys thought while developing this wonderful Solaris service. CIFS is the natural choice for sharing a ZFS file systems with Windows clients. CIFS implements the SMB protocol and it's, moreover, a wonderfully easy service to configure and maintain. Since CIFS exists, I'm not longing for Samba any more. If you mount a CIFS share in a Previous Versions-enabled copy of Windows, you'll automatically get access to ZFS snapshots without the burden of manually accessing .zfs directories.

Conclusion

As you can see in the following screenshot, Solaris ZFS snapshot are visible in the Previous Versions tab:

Conclusions

ZFS, CIFS and Windows Previous Versions are a great team when sharing ZFS file systems to your Windows clients. Windows has got the most usable interface when you need access to your ZFS snapshots. At least once Windows is superior to Mac OS X which has a fancy, usable but pretty basic interface.

HP Solution Center doesn't work in Windows 7

That's the only bad news after a flawless upgrade of a virtualized instance of Windows Vista Ultimate SP2 to Windows 7 Ultimate. The solution center refuses to start claiming that the device is not correctly set up.

I just checked HP website to see if HP Solution Center was available for HP OfficeJet 6500 on Windows 7 and, unfortunately, just a laconic one megabyte USERHPNDU_2017.exe file is present.

Users on HP Website report that reinstalling the Vista software on Windows 7 running setup.exe in Vista compatibility mode should suffice. I'll report on it. Meanwhile I tried to run the already installed software setting the appropriate compatibility flags but it keeps on complaining about an incomplete configuration.

Luckily, that's just a testing Virtual Machine. I wouldn't like to pay-so-much for a Windows upgrade just to discover, once more, that some of my hardware is not compatible.

Boot Configuration Data: removing boot options in Windows Vista

If you tweaked boot options in Windows versions earlier than Vista, you're probably familiar with boot.ini and friends. Today I wanted to give Windows 7 a try and launched the upgrade from Windows Vista Ultimate to Windows 7 Ultimate. Despite the compatibility check performed by the installer did not complain about anything, the installation failed: system restarts always ended with a BSOD. Fortunately, the system upgrade process left Windows Vista untouched and I could boot into it and remove stale installation files.

The last thing I had to remove were the boot options corresponding to the Windows Setup program. Windows Vista introduced a new boot loader architecture and a set of commands to interact with the storage system which holds the boot loader configuration: bcdedit. bcdedit is the Windows Vista equivalent of Solaris' beadm. This is good news: no more tweaking ini files.

To view the current configuration you can issue the following command (beware that you must run the bcdedit command in a command prompt run as Administrator):

bcdedit /enum

[snip]

Windows Setup

-------------

identifier              {cbd971bf-b7b8-4885-951a-fa03044f5d71}

device                  partition=C:

path                    \$WINDOWS.~BT\Windows\system32\winload.exe

description             Windows Setup

locale                  en-US

inherit                 {bootloadersettings}

osdevice                partition=C:

systemroot              \$WINDOWS.~BT\Windows

nx                      OptOut

detecthal               Yes

winpe                   Yes

[snip]

To remove the Windows Setup boot menu entry I issued the following command:

bcdedit /delete {cbd971bf-b7b8-4885-951a-fa03044f5d71}

and the job was done.

Setting up Subversion Client Access Via SSH Using TortoiseSVN

If you read so far, you're probably running your own Subversion repositories on your Solaris box. Fine! Now, let's face the next problem: some of your users needs access from a Windows client. They installed their favorite Subversion client, TortoiseSVN, and tried to checkout your repositories. But no, it does not work.

Setting up users

The first thing to do is setting up properly a bunch of user accounts for your client. If you haven't done yet, it's time to do it, now. Read here.

Preparing some keys for your users

As I told you in my previous post, the best option you have is setting up some public key for your users: configuration on the server side will be easier and your users won't need to enter a password every time they connect to your repositories. If you don't know how to do it, read this other post.

Configure TortoiseSVN

Many people get stuck here. Windows lacks the basic set of commands you need to interact with your remote system over an encrypted connection using the SSH protocol. It may sound strange to you faithful UNIX user but unfortunately that's the truth. Programs such as TortoiseSVN bring their own implementation of the SSH client, although specifically, TortoiseSVN lets you choose an alternate external client. The problem because of which people get stuck is that TortoiseSVN configuration GUI does no mention what-so-ever of SSH authentication. Nothing. That's why, once more, you should rely to The Manual just to discover that TortoiseSVN brings with it a PuTTY client, Plink, which is the command line interface to PuTTY backends.

The problem now reduces to configuring PuTTY to use a public key to authenticate you, save the session configuration and... remember its name! As Plink will use the same configuration registry as your standalone PuTTY, you'll be done.

Checkout your repository

Now that PuTTY is configured, you can check out your first repository over an SSH connection. Just remember not to use the server's URL and use PuTTY session name instead.

Now you should be able to:

• interact with your Solaris-hosted repositories from your Windows clients...
• ... with TortoiseSVN...
• ... and without typing any password.

Moreover, if you set up your Solaris user accounts as I explained you in another post, the key you distributed to your user won't let them even login into your system. You and you're sysadmin will be happy!

Configuring SSH key authentication with PuTTY

If you're a UNIX user, you're probably already using SSH public key authentication. Personally, I use it to avoid typing so many passwords every time I connect to a remote machine. If you're running a Windows client you installed an SSH client to connect to your remote machines. I usually use Cygwin, which gives me an environment very simiilar to what I'm used to. If you didn't feel like installing Cygwin just to establish a SSH connection, you probably chose PuTTY.

PuTTY is a bit different: it's got no .ssh directory to read from, it brings its SSH client implementation with it. If you want to configure PuTTY to use SSH key authentication, you can just follow these steps.

Setting up your keys for PuTTY

Both if you own or not your own keys, you need another program to produce a file for PuTTY to read: PuTTYgen. When you run it, puttygen will let you import your private key and save it in a PuTTY-friendly format or, if you haven't got one, to generate your brand new key. If you prefer not being asked a password by TortoiseSVN again and again, you can just avoid protecting the key with a passphrase and store the key in a safe place. I'll repeat it: store the key in a safe place.

Once you've done with the process, you will have a ppk file you should better store in a safe place! 

Configuring PuTTY

To tell PuTTY to use your key, just open it, go to Connection/SSH/Auth and browse for your key file in the Private key file for authentication... field. Now you can save your session and you're done.

Have fun!

Configuring PuTTY to use UTF-8 character encoding

When it comes to Windows (and Windows programs...) it's never late to "learn" something. Or forget something?

Straight to the point: as I needed a terminal to connect to my Solaris box down there, I decided to go for PuTTY. In this laptop I'm running Windows Vista (I'm not joking...) and I didn't want to install Cygwin for such a basic task.

PuTTY doesn't even intall: you just download it and run it. Fine! As soon as I connect, the first surprise.

I'm not a masochist and I didn't chose that directory name! My Solaris user is running with an UTF-8 encoding:


$ echo $LANG
en_US.UTF-8

and PuTTY is simply misunderstanding it. Well, to say the truth it isn't even trying to understand it. When you launch PuTTY you're presented a dialogue. In that dialogue, if you choose the Window/Translation tab, you'll the able to choose the character encoding PuTTY will be using during the translation process of the received data. Just set it to match your other endpoint encoding like this:

Et voilà! PuTTY is printing characters correctly:

Just a remark for the PuTTY guys: Windows/Translation doesn't seem such a good option name, to me, for a character encoding.

Windows-Solaris interoperability: CIFS permissions and Quicktime idiosyncrasies

Since I had to setup a Windows Vista laptop, I started to use a combination of Solaris technologies to enjoy some easy to setup Solaris-Windows interoperability services. The ZFS-CIFS combination is an excellent way to integrate that Windows machine in my home and work Solaris-based networks. Running CIFS in workgroup mode is sufficient, right now, and almost everything works as expected. I say almost because I hit a strange QuickTime player behavior. It's probably a QuickTime idiosyncrasy, nevertheless I spent some time investigating it.

Files and directories on my ZFS file systems have got the following permissions:

• 600 for files
• 700 for directories
• No ACLs.

That's a pretty simple and intuitive setup. I share some private directories and only my user has got privileges on it. I also mapped with idmap the staff UNIX group, to which my user belongs, with the Windows' Administrators group. Given the permissions sets I'm using it's probably unnecessary, but I didn't like that ephemeral SID showing up in the Windows security tab.

Now, with this setup, when I try to open a MOV files with the QuickTime player, I've got the following error:

Error -43: A file could not be found

Moreover the QuickTime player process, after closing the error windows, remains there hanging around. That's not a big issue but you have to kill it if you want to open it again.

The first thing I checked was if the file is readable. Well, obviously it is. The file is readable and I can copy it in a local folder and launch it from there. It works. But that's not what I want to accomplish.

Second thing I noticed is that, if I use the File Open... feature of the QuickTime player, the error is different: it simply says I haven't got sufficient privileges to open the file. It turns out that, for strange reasons and only in some situations, the QuickTime player was requiring more permissions that I thought it was necessary. I succeeded opening the files only removing some of the special permissions associated with that file. Specifically, the execute file denial (for my user), and the read data and write data denial for the Administrators and the Everyone group. Really, really strange, indeed.

Solaris and Windows interoperability: using Solaris CIFS to share directories and to map identities

In an earlier post I described how easy is setting up CIFS and share Solaris directories with Windows clients. ZFS sharesmb properties, moreover, makes the process even easier: just set it to on, or to name=sharename to change the share's default name, and the job is done.

The next step in configuring your CIFS server is: how do you assign privileges to your user? Well, despite what you might be accustomed during your life with Samba, Solaris has been enhanced and now it supports Windows SIDs and Windows ACLs. As usual, Solaris documentation is the best place to look for information. In this post, I'll give you a brief introduction.

Let's suppose you completed the steps in the previous post and you did set up a share correctly. Right now, you'd be probably working on it from your Windows client. The first thing you could be noticing while inspecting the security permission of the shared folder is the following: your solaris user is listed and an unknown SID might be listed as well. What's that SID? Let's open a shell.

The Identity Mapping Service is a service whose purpose is just that: mapping identities between Solaris and Windows. You can dump the currently mapped identities with the command idmap dump -nv. The first thing you might want to do is mapping your user's default group into a Windows group. In this example I'll map the Solaris staff group into Windows' Administrator group:

$ idmap add wingroup:Administrators@BUILTIN unixgroup:staff

This is a bidirectional map which says both operating systems what corresponds to what. After logging in and out you can recheck your shares security permissions. In Solaris I have:

$ ls -adl software

drwxr-xr-x  14 enrico   staff         14 Aug 18 17:29 software

while on Windows I read:

Really easy, isn't it? The same way you can change permissions with Solaris ACLs, you can do it from Windows. The following directory has got the same permission set depicted in the previous figures:

$ ls -dV subversion/
drwxr-xr-x   2 enrico   staff          3 Feb 22 01:10 subversion/
                 owner@:--------------:-------:deny
                 owner@:rwxp---A-W-Co-:-------:allow
                 group@:-w-p----------:-------:deny
                 group@:r-x-----------:-------:allow
              everyone@:-w-p---A-W-Co-:-------:deny
              everyone@:r-x---a-R-c--s:-------:allow

Basically, it's a directory owned by enrico:staff, with a permission mask of 755 and no ACLs. Now let's add the SOLARIS\enrico user a couple of permissions: Delete subfolders and files and Delete. As soon as you do that, you'll find:

$ ls -dV subversion/
dr-xr-xr-x+  2 enrico   staff          3 Feb 22 01:10 subversion/
            group:staff:-w-p----------:-------:deny
              everyone@:-w-p---A-W-Co-:-------:deny
            user:enrico:rwxpdD-A-W-Cos:-------:allow
            group:staff:r-x----------s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow


That is: modifications done in Windows are correctly reflected on the Solaris side.

This is really the starting point. You can establish users and groups maps, you can set your Solaris ACLs and having them propagated to the Windows clients. In domain mode you can also rely on a directory service for identity mapping.

Happy interoperability!

Windows interoperability: sharing folders with the SMB protocol using Solaris CIFS server

Interoperability between Solaris and Windows has improved and is improving very much. In the case of file systems sharing, the situation is now pretty good. There's no need of installing Microsoft Services for UNIX on top of your Windows servers to be able to share folders with Solaris. One of the last additions in the Solaris operating system is the CIFS Server which, as the official project page @ OpenSolaris.org states:

The OpenSolaris CIFS Server provides support for the CIFS/SMB LM 0.12 protocol and MSRPC services in workgroup and domain mode.

The official project page is the ideal starting point to look for information about installing and using the CIFS Server and Client components in Solaris. In this blog I will describe how to quickly configure the CIFS Server to be able to share folder between your Solaris and your Windows environments. I will use the new, and very simple, sharing semantics introduced in the last versions of the ZFS file system.

What's impressive of these tools is the ease of use and administration. Both ZFS commands and CIFS Server commands are few, easy and intuitive. Sharing a ZFS file system is a no brainer and just few one-time configuration steps are necessary to bring your CIFS Server up and running.

Preparing a ZFS file system

We will share a ZFS file system which we usually create with the following command:

# zfs create file-system-name

Once the file system is created, we configure the SMB sharing:

# zfs set sharesmb=on file-system-name

As described in the official ZFS documentation (for Solaris Express) or in the zfs(1M) man page, the sharesmb property can be set to on, off or [options]. The last syntax is useful to pass parameters to the CIFS server. The most useful is the name parameter, which lets you override the automatic name generation for the SMB share:

# zfs set sharesmb=name=smb-name file-system-name

The automatic name generation works fine but sometimes it must change illegal characters which appear in the dataset name.

Setting up CIFS Server in workgroup mode

The CIFS Server can work in both domain and workgroup mode. The domain mode is useful when you connect to a Windows domain and the very flexible configuration is well detailed in the official CIFS service administrator guide. In my case the workgroup mode is fine and that's the configuration I'll detail here.

Starting the service

If it's not started yet, you'll have to start the CIFS server. Please be aware that if you're running Samba in your Solaris box, you'll have to stop it first.

# svcadm enable -r smb/server

Joining a workgroup

To be able to use shares, you have to join a workgroup:

# smbadm join -w workgroup

Configuring password encryption

To be able to authenticate you must configure Solaris to support password encryption for CIFS. To do this, open the /etc/pam.conf file and add the following entry:

other password required pam_smb_passwd.so.1 nowarn

Generating or recreating passwords

Now that CIFS password encryption has been configured, you'll have to regenerate the passwords for the users you want to use with it because the CIFS service cannot use Solaris password encryption, which was used before /etc/pam.conf was reconfigured. The passwd command will take care of that:

# passwd user
[...]

Conclusions

With just these few steps you'll have your CIFS server up and running in workgroup mode. Now you can share whichever ZFS file system you want just setting its sharesmb property.

Enjoy!

GPT protective partition after moving a removable disk from a zpool to Windows

In an emergency, I needed an USB disk to backup some data from a Windows XP PC and the only disk I could take was a Lacie disk used as a cache device on a zpool. No problem removing it from the pool and formatting it again, thought I.

Problem is that when I plug the disk on the troubled Windows machine and go to Logical disk manager to format it, I discover that the partition appears as a GPT protective partition and you cannot do anything to it.

Cleaning a GUID Partition table

Long story short: having been part of a zpools, that disk was labeled with an EFI label. EFI adds support for GUID partition tables, and that (partially) explained the behavior of the Logical disk manager. I didn't even imagine that Windows XP would know about EFI of GUID partitions tables and I understand why it didn't let me touch that disk. What I didn't know was how to clean the disk to be able to format it with NTFS. Fortunately, Google always helps who knows what to search, and I discovered about the existence of a command line utility called diskpart. With diskpart it was easy to clean the disk and format it again. Instructions are straightforward:

• open a command prompt
• launch diskpart
• list disks with the list disk command
• select the disk you want to clean with the select disk command
• clean the disk with the clean command

That's it.

Running Windows on Sun xVM with Solaris Express Community Edition

Introduction

I'm waiting to see Sun xVM Server. It's a long wait, this, and I hope to see it soon. I've being using Sun xVM VirtualBox since quite a while and I'm really happy with it. The underlying technology is completely different, but I'm experiencing a feeling of hope that makes me think that Sun xVM Server quality will be at least the same.

Recently, I needed to set up an Active Directory for development purposes and while part of the team is happily running its .net development stack on top of a Sun xVM VirtualBox Windows guest, a quick test drive showed us that running a server on top of Sun xVM VirtualBox wasn't practical at all. That's why I set up a Solaris Express Community Edition machine: not only I wanted to test Sun xVM but I needed it.

All the commands shown in this post were executed on Solaris Express Community Edition build 103. Be aware that the output and the commands themselves are not stable yet.

The feeling of running unsupported software

It's unpleasant. Solaris Express Community Edition is rock solid. I'm using it on many machines and never let me down. But running a critical component on such an experimental technology, well, was something I wanted to avoid. That's the rationale behind using Solaris 10 even in our development machines, where I'm sure that Solaris Express Community Edition (or even OpenSolaris now), would greatly do their job; and the developers would also probably be happier.

I waited months hoping that Sun released Sun xVM Server just in time for us to be on schedule but project deadlines pushed me to deploy Solaris Express Community Edition instead. Documentation is not as up-to-date or easily retrievable as Solaris 10 is, but with a little help from Google and especially from a Sun white paper, Install Sun xVM Hypervisor and Use It to Configure Domains, setting up Windows 2003 Server guests was not that hard.

Setting up Windows

Setting up Windows 2003 Server was not as straight forward as I thought. The first times I tried it, indeed, I get stuck for a CD-related problem and that's where Sun's cited white paper really helped me a lot.

Checking up the system

The first thing to check is if xVM is installed and running. The following command should produce this output:

# /usr/bin/pkginfo | grep SUNWxvm
system SUNWxvmdomr Hypervisor Domain Tools (Root)
system SUNWxvmdomu Hypervisor Domain Tools (Usr)
system SUNWxvmh Hypervisor Header Files
system SUNWxvmhvm Hypervisor HVM
system SUNWxvmipar xVM PV IP address agent (Root)
system SUNWxvmipau xVM PV IP address agent (Usr)
system SUNWxvmpv xVM Paravirtualized Drivers
system SUNWxvmr Hypervisor (Root)
system SUNWxvmu Hypervisor (Usr)

Once logged in in the system running the hypervisor, be sure that relevant services are running:

# /usr/bin/svcs | grep xvm
[...]
online 0:15:07 svc:/system/xvm/console:default
online 0:15:08 svc:/system/xvm/xend:default
online 0:15:08 svc:/system/xvm/domains:default
[...]
online 0:15:09 svc:/system/xvm/store:default

The default network interface

The hypervisor, unless differently instructed, will use the first available NIC when setting up the network for its guests:

# dladm show-link
LINK CLASS MTU STATE OVER
e1000g0 phys 1500 up --

To specify the desired NIC for the guests, you can set xend service's config/default-nic property:

# /usr/sbin/svccfg -s xend 'setprop config/default-nic = astring: “yourNIC”'

and then restarting the services with svcadm.

Assigning space on the disk

You can assign space to your guest both using a dedicated ZPool or on a regular file. Using ZFS is undoubtedly easier but I had no ZPool available on that machine so I had to setup a regular file on UFS:

# mkfile 20g file-path

I created two 20 GB files which I used as disks for the new guests.

Installing the host OS

From here ahead, I just suggest you to follow the instructions on the white paper I linked above. Everything went as planned, including the glitches during Windows 2003 Server installation described in that document.

Running the guest

Basic commands

In this xVM version, you still have to use both virsh and xm to have a complete set of administrative command while managing your hosts. In the future virsh should completely replace xm but that's not yet the case.

Booting and shutting down a domain

To boot and to shutdown a domain you can use the following commands:

# virsh start [domain-name]
# virsh shutdown [domain-name]

In the case of Windows, I still prefer to connect to it and shut it down from its GUI.

Rebooting a guest

A guest may also be rebooted directly with the following command:

# virsh reboot [domain-name]

Suspending and resuming a guest

To suspend and subsequently resume a guest you can use the following commands:

# virsh suspend [domain-name]
# [...]
# virsh resume [domain-name]

Dumping a domain configuration

To dump the domain configuration in the case you need to examine it and modify it, you can use the following command (virsh will dump it on the standard output):

# virsh dump-xml [domain-name]

Loading a domain configuration

If you previously dumped and modified a domain configuration, you can redefine the domain using this command:

# virsh define [domain-configuration]

Determining the VNC display

To determine the display that VNC is using for a particular domain, you can use the following command:

# virsh vncdisplay [domain-name]

Examining existing domains

To determine the status of every existing domain, you can use the following command:

# virsh list --all
Id Name State
---------------------------------
0 Domain-0 running
2 winsrv2003 blocked

Domain winsrv2003 is listed as in a blocked state. This usually means that the domain is not running because it may be idle or waiting for I/O.

Block device related commands

The following commands are used to manage guests' block devices.

Mounting a CDROM

To mount a cdrom on a guest you can either directly mount the physical device or mounting and ISO image of the medium. The commands are:

# xm block-attach [domain-name] [device-type]:[path-to-device] [physical-drive]:[device-name] [options]

For example:

# xm block-attach [domain-name] phy:[path-to-device] hdb:cdrom r
# xm block-attach [domain-name] file:[path-to-device] hdb:cdrom r

Checking for device status

To check the block device status you can use the following command:

# xm block-list [domain-name] --long
(768

((backend-id 0)

(virtual-device 768)
(device-type disk)
(state 1)
(backend /local/domain/0/backend/vbd/11/768)

)

)
(5632

((backend-id 0)

(virtual-device 5632)
(device-type cdrom)
(state 1)
(backend /local/domain/0/backend/vbd/11/5632)

)

)

Unmounting a device

After detecting the device ID using the block-list command described in the previous section, you can use the following command to unmount a device:

# xm block-detach [domain-name] [device-id] -f

Before detaching a block device, the device should be unmounted and ejected in the guest OS first.

Impressions

The Windows guest runs pretty well, even if the machine seems slower while running the xVM kernel. I'm still doubting, moreover, if there's sort of a memory leak because as time passes by, vmstat shows that free memory and free swap are almost zero and the machine is indeed swapping on the disk.

For example, I'm running two Windows 2003 Server since a couple of SXCE build iterations and on build 103 I still continue to have the same problem. The machine is a Sun Ultra 20 M2 with 8 GB of RAM memory. Both domUs were dedicated 1 GB setting both mem-set and mem-max. This problem even shows up the same way even if I only boot one domU. When I boot the Windows domU, everything's fine and memory usage seems reasonable: dom0 has more or less 6 GB of dedicated memory and an unlimited mem-max. As times goes by, free memory goes down, free swap goes down and the machine begins to swap to disk and a moment comes I have to reboot. The effect is pretty clear with vmstat: free memory goes down to more or less 100 MB, free swap goes down too and the machine begins slowing down.

I found the description of this bug on Solaris Express release notes:

xVM Hypervisor Running Out of Memory

When running some non-Solaris domUs, you could encounter an issue where xVM hypervisor runs out of memory. This will generally be reflected by error messages generated to the dom0 console, in some cases in such high quantities that a reboot of the dom0 might be required to recover.

To avoid this, it is suggested that when running a non-Solaris domU, you manually balloon the amount of memory used by dom0 down to a smaller amount before booting the domU.

For example, if the dom0 is using 3500Mb, which can be determined via the xm list command, you would issue the following command to reduce its memory usage to 3000Mb:

xm mem-set Domain-0 3000

This should not be necessary when using a build-81 based dom0, or later.

This bug seems to explain the behavior I'm experiencing but it seems not applicable because I'm running build 103, while this bug is related to builds earlier than 81.

Other glitches

I experienced problems mounting and ejecting ISO images on Windows 2003 Server cdrom. Indeed, up to Solaris Express Community Edition build 103, I was experiencing bug 6749195: empty CD-ROM disappears from HVM domains. And when it disappeared, you had to reboot the domain. This made xVM unusable on production, at least if you needed the cdrom even only from time to time.

On build 103 and 104 I'm still noticing instabilities in xm block-attach behavior and I prefer using xm block-configure even when mounting an iso image on an empty cdrom.

Conclusions

Globally, I must say I'm pretty happy with xVM, such as I tried it on Solaris Express Community Edition since build 103. Nevertheless, as I said in the opening, the feeling of running unsupported software isn't that good when part of your business is relying on it. Still, I'm missing the performance, the stability and the ease of use of Sun xVM VirtualBox but I hope they'll find their way into Sun xVM Server.