Solaris 10 and VMWare vmxnet ethernet driver

The problem that I had been experiencing was that I was unable to install the VMWare vxmnet ethernet driver onto a Solaris 10 x86 server running on a VMWare vSphere 4.0 server.

The solution to getting the vmxnet interface to work is as follows:

1) install stock e1000 ethernet interface on a Solaris VM
2) install the VMWare 4.0 tools on a Solaris VM
3) halt and power off VM
4) install a second ethernet interface onto a Solaris VM, using the vmxnet3 driver
5) ifconfig vmxnet3s0 plumb
6) ifconfig e1000g0 unplumb
7) mv /etc/hostname.e1000g0 /etc/hostname.vmxnet3s0
8) reboot

The trick is to have two ethernet interfaces (e1000 and vmxnet3) and just unplumb from Solaris the e1000 interface. Don't remove the e1000 interface from the VMWare host configuration.

Solaris syslog-ng error

If you get an error like:

# svcs syslog-ng
STATE STIME FMRI
maintenance 8:50:44 svc:/system/syslog-ng:default

# svcs -xv syslog-ng
svc:/system/syslog-ng:default (syslog-ng)
State: maintenance since Mon Dec 14 08:50:44 2009
Reason: Start method failed repeatedly, last exited with status 1.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/share/man -s 1M syslog-ng
See: /var/svc/log/system-syslog-ng:default.log
Impact: This service is not running.

# cat /var/svc/log/system-syslog-ng:default.log
[ Dec 14 08:50:42 Disabled. ]
[ Dec 14 08:50:42 Rereading configuration. ]
[ Dec 14 08:50:43 Enabled. ]
[ Dec 14 08:50:43 Executing start method ("/lib/svc/method/svc-syslog-ng") ]
Error parsing command line arguments: Conversion from character set '646' to 'UTF-8' is not supported[ Dec 14 08:50:44 Method "start" exited with status 1 ]
[ Dec 14 08:50:44 Executing start method ("/lib/svc/method/svc-syslog-ng") ]
Error parsing command line arguments: Conversion from character set '646' to 'UTF-8' is not supported[ Dec 14 08:50:44 Method "start" exited with status 1 ]
[ Dec 14 08:50:44 Executing start method ("/lib/svc/method/svc-syslog-ng") ]
Error parsing command line arguments: Conversion from character set '646' to 'UTF-8' is not supported[ Dec 14 08:50:44 Method "start" exited with status 1 ]
[ Dec 14 08:52:06 Rereading configuration. ]

This has nothing to do with the configuration, merely a missing charset.alias file.

To correct:

# ln -s /usr/lib/charset.alias /usr/local/lib/charset.alias

# svcadm clear syslog-ng

# svcs syslog-ng
STATE STIME FMRI
online 8:59:38 svc:/system/syslog-ng:default

Change WMware vSphere IP Address

To change the IP Address of a vSphere 4.0 server:

1) check the service console:

# esxcfg-vswif -l

[will return the current IP information and the name of the Service Console, in most cases: vswif0]


2) run the esxcfg-vswif command with the new information

# esxcfg-vswif -i newipaddress -n newsubnetmask vswif0

3) check the following files:

# cat /etc/sysconfig/network-scripts/ifcfg-vswif0

make sure the new information is in the file.

# cat /etc/sysconfig/network

4) restart the network -- this will disconnect you unless you are on a console:

# service network restart

You should be done at this point.

Citrix XenApp Server Application Installation Best Practice

Prior to installing an application on a Citrix XenApp server:

Start --> run --> change user/install

[install the applications and all updates]

Start --> run --> change user/execute

That will ensure that all of the registry settings will work under XenApp.

Astaro not updating

For Unified Threat Management at some of my sites I like to use the Astaro Security Gateway (ASG). Sometimes the update process gets wedged and new firmware won't download to the box.

There is a command line ssh access that will allow a user to get into the system, but it's disabled for security reasons. In order to fix the update problem, ssh must be enabled.

I won't go into how to enable ssh or how to log into the system, but I will detail the fix:

Once logged in as root, check the files in /var/up2date/sys -- if there are files there, remove them and then upload the new firmware via scp to /var/up2date/sys.

After the files have been uploaded, type the following commands:

audld.plx

auisys.plx --rpmargs --force

This will verify the digital signature of the update file and if correct, install the firmware update and reboot the ASG.

Problem solved.

VMware service console memory setting

I had been running vmware ESX server 3.5 with the default memory setting of 272MB. This caused a couple of host migration and snapshot timeouts.







VMWare's suggested value is 800MB. So you click on the Properties... link in the VIC or vSphere Client and change the number:












The setting won't take effect until the system is rebooted and the Memory Configuration now reflects that:

Solaris Live Upgrade

Never tried Live Upgrade, and my first attempt was a disaster -- now that's not to say it doesn't work, but my configuration didn't lend itself to the perfect Live Upgrade process. I had non-global zones mounted from SAN volumes on /zones and when I ran Live Upgrade I didn't realize that I needed to size my system for that and add in additional SAN volumes to copy the non-global zones as well.

The other major problem was that I didn't have all of the correct patches for Live Upgrade and ran into a major ludelete bug that when run deleted files in /zones and destroyed my non-global zones.

So, now that I realize the issues, here are the command that I used. The logic is sound and I've since rebuilt the server and put the non-global zones on the root filesystem so that when I try Live Upgrade again I won't be bitten by these issues.

I added a second san volume that's the same size as server's current boot volume.

1) copy over the Solaris 10 iso and mount it via loopback:

# mkdir /iso; mount -F hsfs -o ro `lofiadm -a /var/tmp/sol-10-u6-ga1-sparc-dvd.iso` /iso

2) format the new volume:

c2t6000D31000089A000000000000000043d0s0 existing root volume
c2t6000D31000089A0000000000000000E9d0s0 new root volume

3) patch the live upgrade distribution

SunSolve document: 206844:


3) install the live upgrade packages from the distribution:

# cd /iso/Solaris_10/Tools/Installers
# ./liveupgrade20 -noconsole -nodisplay

4) run the lucreate command to create a copy ofthe active boot environment

# lucreate -c sol10807 -n sol101008 -m /:c2t6000D31000089A0000000000000000E9d0s0:ufs

[where sol10807 is the name of the original boot disk and sol101008 is the name for the new boot disk]


5) after the new boot disk is created, the upgrade is run against the new boot disk:

# luugrade -u -n sol101008 -s /iso

6) after the upgrade is done, activate the new boot environment:

# luactivate sol101008

7) init 6

8) test the new boot environment and patch it

9) after testing remove the initial boot environment with the ludelete command, but save the original SAN volume for future upgrades.

In the future I could run patches using Live Upgrade.


Check out this SUN article.