I gave a talk tonight on network virtualization at the Atlanta UNIX users group. The talk focused on the OpenSolaris network virtualization project (project Crossbow), and described Crossbow and how to use it. I posted the slide deck I used on my website, so you can grab the presentation and the latest Nevada build and start creating virtual networks today!
While catching up on some of my favorite blogs, I came across a post pertaining to parallel zone patching by Jeff Victor. In his write up, Jeff discussed a couple of methods for decreasing the time it takes to patch a host with one more more zones. Of the methods listed, the “Zones Parallel patch” feature caught my eye:
“Sun has developed an enhancement to the Solaris patching tools which is intended to significantly decrease the elapsed time of patching. It is currently being tested at a small number of sites. After it’s released you can get the Zones Parallel Patching patch, described below. This solution decreases the elapsed time to patch a system. It can be combined with some of the solutions above, with varying benefits. For example, with Live Upgrade, parallel patching reduces the time to patch the ABE, but doesn’t reduce service downtime. Also, ZPP offers little benefit for the detach/attach-on-upgrade method. However, as a stand-alone method, ZPP offers significant reduction in elapsed time without changing your current patching process.”
It can take a looooooong time to patch hosts with multiple zones, so I can’t wait to get my hands on this!
I built a Fedora Core 10 host this weekend, and configured it to use DHCP to retrieve its IP address and network configuration during installation. Once the host was built, I decided to update the ifcfg-eth0 file to use static IP addresses. Here is the configuration I added to /etc/sysconfig/network-scripts/ifcfg-eth0 to assign the static IP address 192.168.1.50 to the server:
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:0c:29:a0:ad:c7
IPADDR=192.168.1.50
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
TYPE=Ethernet
GATEWAY=192.168.1.1
DEFROUTE=yes
I copied this configuration from another Fedora Core host on my network, but wanted to paste it here for future reference.
I recently debugged an issue where a host panicked with the following message:
Apr 3 04:41:44 pluto.prefetch.com genunix: [ID 663943 kern.notice] Unrecoverable Machine-Check Exception
These errors are typically generated due to CPU or memory faults, but on this specific machine nothing was being displayed when I checked the fault and errors logs. Upon closer inspection, it looked like the fault manager wasn’t running and had transitioned into the maintenance state:
$ svcs -a | grep fmd
maintenance 4:46:25 svc:/system/fmd:default
After poking around Sunsolve, I noticed that there were a number of issues that can cause fmd to enter the maintenance state. In this specific case, the daemon was core dumping at startup so I had a core file readily available to help debug the source of the problem. Upon inspecting the panic string, it turned out that we were bumping into bug #6672662. This bug occurs because one of the libtopo maps is incorrectly named. Fixing this issue is as simple as renaming the “storage-hc-topology.xml” file to “storage-hc-topology.xml.org”:
$ mv /usr/platform/i86pc/lib/fm/topo/maps/storage-hc-topology.xml /usr/platform/i86pc/lib/fm/topo/maps/storage-hc-topology.xml.org
Once the topology map was renamed, fmd started up fine:
$ svcadm clear fmd
This also allowed the fault manager to kick into action and make a diagnosis of the faulty hardware:
$ fmadm faulty -a
STATE RESOURCE / UUID
-------- ----------------------------------------------------------------------
faulted cpu:///cpuid=10
f202538b-9dbe-6f59-bd04-87f9a0954ce8
-------- ----------------------------------------------------------------------
$ fmdump
TIME UUID SUNW-MSG-ID
Apr 03 16:50:16.0797 f202538b-9dbe-6f59-bd04-87f9a0954ce8 AMD-8000-67
The fmdump data revealed that we had a faulty DIMM, and provided and bank and DIMM number of the defective hardware. Debugging issues can be a lot of fun, especially when you get to the bottom of a system panic! :)
By default, Fedora core 10 will install in graphical mode. This is not ideal for the vast majority of my hosts, since they run inside a VMWare virtual machine. To get Fedora Core 10 to install in text mode, you can hit the key at the install screen and add the keyword “text” to the end of the boot options.