h0bbel.p0ggel.org

Over time the boot partition on a Windows Server 2003 installation might just turn out to be too small. There can be various reasons for this, but the fact remains that over time you will accumulate data on the boot drive that you didn't take account for when you set it up initially.

Luckily I run almost all of my servers in a VMware based virtualized environment, where it's easy to expand the the virtual disks. The problem is that Windows Server 2003 doesn't let you easily expand the boot volume, at least not without downtime. I've previously talked about using tools like GParted to expand the boot volume but there are easier ways to do it and prevent downtime at the same time!

All you need is love. No,wait, that's something else entirely! All you need is ExtPart. ExtPart is a lovely little 36KB tool that Dell has provided to expand partitions on Dell based servers and storage systems. It is a little known fact that ExtPart can do the job in any 32 bit Windows Server 2000 or 2003 based install (no 64 bit support, sadly), and in Server 2008 there are other methods of doing this.

Enough talk, lets get down to the business at hand.

1. Download ExtPart from the Dell download site
2. Expand your boot volume, either via the Virtual Infrastructure Client or via vmkfstools
3. Run ExtPart inside your VM to expand your boot volume to the new size

Thats it. The following screenshots outline the process very well, without having to guide you through each step. Have a look!

It can't get much simpler that this, honestly.

Today, all of a sudden one of my VMware ESX Server hosts went awol. It didn't completely disappear, as the VMs running on it were all operational and the host itself was responsive to SSH connections. The problem was that the my VI3 client listed the host as unresponsive and direct connections to the host from the VI3 client was unsuccessful as well.

As I was able to SSH to the host in question, and given the fact that all the VMs were operational, I quickly ruled out network connectivity issues between the VI and the host. Inspection of the logs gave me no real clues either, but I had a sneaking suspicion that the problem was related to problems with the management agents on the host.

A quick "service mgmt-vmware restart" later the host was back in business as usual and all things were good in VMware land yet again.

For some time, I've been having some issues with how Lenovo System Update uses the computers Regional Settings to determine which language it should use when installing drivers and software.

It turns out that there is indeed a way to override the automatic language selection, without having to resort to changing your Windows Regional Settings.

While reading through deployment documents for Active Directory integrated System Update, I found this little gem:

[HKEY_LOCAL_MACHINE\SOFTWARE\Lenovo\System Update]
"LanguageOverride"="EN"

That registry setting sets a language override that System Update checks before it determines which language to use. If the registry key is not present, or has invalid data in it, System Update does it's normal auto detection.

Valid two- and three- letter language codes are the following:

• DA (Danish)
• NL (Dutch)
• EN (English)
• FI (Finnish)
• FR (French)
• DE (German)
• IT (Italian)
• JP (Japanese)
• KO (Korean)
• NO (Norwegian)
• PT (Portuguese)
• ES (Spanish)
• SV (Swedish)
• CHS (Simplified Chinese)
• CHT (Traditional Chinese)

Finally an easy way to override the language selector, and prevent Lenovo from "polluting" your computer with localized software you don't want.

Seems like Microsoft is having problems with delivering some of the promised features that were to be present in Viridian (Longhorn Virtualization). Yesterday the following was published by Windows Server Division WebLog:

So we are making the following changes, and postponing these features to a future release of Windows Server virtualization: · No Live migration · No hot-add resources (storage, networking, memory, processor) · Support limit of 16 cores/logical processors (e.g., 2 processor, quad-core systems is 8 cores; or 4 processor, quad-core system is 16 cores)

The lack of initial support for over 16 cores is one thing, but no hot-add of resources and especially no Live Migration was a surprise to me. Perhaps thats why you aren't really allowed to migrate virtual machines to often?

Jokes aside, I think this is a somewhat major blow for Viridian and Longhorn, I really did think at least Live Migration would make it into the final product. After all, thats one of the key points with VMWare VI3, and makes management of the host systems much easier and reduces scheduled downtime to a minimum.

The newest version of the Gallery Appliance has now been available for a couple of weeks, and I had a look at the rPath download statistics today.

As far as I can see, it's been downloaded nearly 2000 times in the 19 days since it's release.

Not bad, not bad at all.