wildness

I've recently had to apply the 126106-40 core patch for SUN Cluster and had some issues with it.. Seeing on the Internet, some issues with this patchs are documented by Juergen Scheich's blog and describing a howto fix some of them. Actually, the error I had was a bit different from the "loaddid" cycling dependencies that was found on his blog. I had a similar issues with the sysidtool:net service which gave me the almost same error as the loaddid did. No pun intented ;-)

Applying the same procedure as found on Juergen's blog fixed also that issue! So you can just:

1. Boot in non clustered mode
2. Remove the loaddid service from SMF: svccfg delete loaddid
3. Import it again from the patch's XML file: svccfg import /path/to/patch/loaddid.xml
4. Refresh the service: svcadm refresh loaddid
5. init 6

This has not been faced on all the node of the cluster I was patching, but I thought it was worth a note here ;-)

Every sysadmin that has upgraded or patched a system running multiples zones will tell it, the upgrade was an undefinably long process.

When you consider that some SPARC machines are running now with 256 threads, it's a shame that such boxes are upgrading with a single thread (each zone sequentially, I mean). This is the end of a long wait ! SUN releases today patches that introduces parallel patching of zones.

It seems that we just need to apply 119254-66 (SPARC) or 119255-66 (x86) patche to take benefit from this feature. After the patchadd, just set the number of zones that should be patched in parallel by editing the file /etc/patch/pdo.conf and sets the value of num_proc var.

Happy (live) patching!

As I have done in the past with UFS, and as already explained here in the "Migrate partition with minimal downtime..." article, I'll explain how to migrate a ZFS volume with minimum downtime.

What could be done during working hours without impact on the mounted filesystem:

• Take a snapshot of the volume to copy:

zfs snapshot vs4f8-pool/test@v1

• Send this snapshot accross the new ZFS volume:

zfs send vs4f8-pool/test@v1 | zfs receive vs4f8-pool/newtest

When the outage time has come, just issue following commands:

zfs snapshot vs4f8-pool/test@v2
zfs send -I vs4f8-pool/test@v1 vs4f8-pool/test@v2 | zfs receive vs4f8-pool/newtest

The last command should be as quick as hell... As your downtime. You could now restore the option on the "newtest" volume and start ot use it.

This same procedure could also be used to migrate volume across network, as the zfs send and receive commands could be piped with ssh.

ERROR: The following required file systems are not mounted by the currently running OS </toto>
ERROR: All required PBE file systems are not mounted.

This is the message I stumbled upon today while trying to create a Live Upgrade environment for a production server... And indeed, the so-called /toto was properly mounted.

A colleague just look at the problem and say "oh, just mount a dummy filesystem and it will work."

What the h... ?!

# mkdir /tmp2 ; mount -F lofs /tmp /tmp2

And god, It worked like a charm...