Windows 7 - Product Key Is Not Valid

When reinstalling W7 (after all, it is Christmas) I was advised that my product key was not valid. Me... Use an invalid product key... Never! And besides, this is a retail upgrade pack.

So what's wrong?

Turns out this is a known issue where under a normal reinstall, your product key will be rejected. At issue is the fact that his is an upgrade disk rather than a "full version". It assumes you have an existing OS. The good news is there is a Microsoft work around.

http://windows.microsoft.com/en-US/windows7/Windows-7-activation-error-invalid-product-key

To save you the effort of reading their propaganda:

1. Select Custom Install.
2. Highlight the target disk.
3. Click Advanced.
4. Click Format.

After the second install completes, you will be able to use your product key.

AMD Athlon 64 Family CPUs with SVM

In my search to tell which AMD CPUs support the HVM virtualization extension, SVM, I found a page at XenSource site. Not only does it cover AMD, but also the totally convoluted Intel VMX issue. One would imagine that by now all chips would be virtualization optimized, but not yet. For AMD:

older Athlon™ 64 processors above 4000+
Athlon™ 64 X2 processors above 4800+
all AMD Athlon™ X2 processors (I guess they're dropping the "64")
all AMD Athlon™ X2 BE, LE, EE processors
all AMD Phenom™ X3 and X4 processors

They also mention Turion, but I'm satisfied with my laptop, as is.

"CompUSA" Extreme 908 Liquid Cooled PC

I got an e-mail from CompUSA.com about their new system, the Extreme 908, with liquid cooling system. Now I think liquid cooling is a great idea, but does anyone else see a problem with this design:I'll give you a hint: Think about gravity and leaking pipes.

Tera Bites fdisk

For half a dozen years, I've been showing people how to use fdisk in varying capacities including positions as a technical trainer for Red Hat and VMware. I had a standard joke that:

...you can specify a partition size K's, M's, or G's, but I've not had a chance to test if T for terabyte will work.

Today, I had the chance:

Command (m for help): n
Command action
e   extended
p   primary partition (1-4) p
Partition number (1-4): 1
First cylinder (1-182401, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-182401, default 182401): +1T
Unsupported suffix: 'T'.
Supported: 10^N: KB (KiloByte), MB (MegaByte), GB (GigaByte)
2^N: K (KibiByte), M (MebiByte), G (GibiByte)
Last cylinder, +cylinders or +size{K,M,G} (1-182401, default 182401):

So, fdisk does not support terabytes. This was under Fedora 11, so its a somewhat recent distro. I'm sure thee is probably a replacement somewhere that does work, but not using fdisk is like not using a screwdriver, just because a Ryobi 18v power driver is available.

The good news is that fdisk isn't broken, per se: +1024G works just fine.

P2V Happiness

It worked. I was able to use the Citrix Xenconvert to P2V a Windows XP Home system to a VM on a XenServer 5. There were a few lessons learned that should have been obvious... or maybe documented.

Citrix XenConvert works differently than some other P2V utilities in the respect that most of its operations are offline. It creates the image on the local hard drive, and does not contact the virtual infrastructure until the image is finished and ready for import. This is good because it prevents network issues from preventing image creation. The downside is that it requires the source machine to have 60% free space. (Preferably on a second disk.)

On the server side, you have to have a default landing zone (Storage Repository) for the imported VMs. I forgot to define the default SR, so my import failed. The good news is that the image was retained on the source machine, so I was able to transfer the image, and import directly.

It took about an hour to create on the source side, but about four hours to import the image on the server side. This is because the server is "governed" to prevent impact on production VMs. (In the real world, I'd have a staging server just for imports, deployments, and installs.)

Last detail is that once on the server, I had to strip the hardware specific software. The drivers were already loaded.

P2V, Windows XP, and SP3

In the continuing saga of P2V, my last plan was to wipe out the Linux instance (gasp!) on the target machine and attempt the process as strictly Windows XP. This box is an HP, so I fired up the recovery partition, and put it back to factory defaults. Of course that means there was 5 gig of garbage-ware on the C: drive, so I invested some time uninstalling stuff. Since it will once again be a dual boot system, I left things like multimedia and DVD burning software in the instance.

Once I had C: down to 10Gb (still bloated) I decided I would install SP3 on the physical machine. The plan was that the physical drive would handle the service pack better than the virtual drive. Much to my dismay, the machine booted, crashed, and rebooted. I assumed my server based copy of SP3 had been corrupted.

I was able to boot to safe mode, uninstall SP3, and recover the system to a normal desktop. That confirmed SP3 was the culprit. This time, I used Windows update. And... It crashed again. Same problem: perpetual reboot.

After loosing another hour monkeying with Microsoft's OS, I found that there is a known bug with SP3 effecting some HPs with AMD processors. Oh, thanks. I found a workaround for the problem on Jesper Johansson's blog. He's written a VBS utility that will prep the system for SP3. In my case, it worked retroactively.

At this point, SP3 is loaded, and P2V is running. Let's see what happens next.

Windows P2V Failures

First, the bad news: I have made several attempts at doing a Windows P2V, and they have all failed. Last night's attempt with the Citrix XenConvert software was no better... Except it lead me to realize why my attempts were all dismal failures.

Before we get to the the why, let me point out that Citrix XenConvert is one seriously cool tool. More on the later.

Now, the good news: All my P2V attempts have grabbed the drive from the Windows system (all have been XP), and written the content to the VMs drive. I can mount the drive and see the NTFS partition. When I boot the VM, they uniformly refuse to load.

And the problem is... All my Windows systems are dual boot. This means that when the P2V software packages the physical machine, it grabs the MBR and the NTFS, but misses the /boot partition. Without /boot, it can't get the grub.conf to realize that it doesn't need /boot.

The solution should be fdisk /mbr, but in order for that to work, you needed the Administrator password to the physical system. (Notice we are talking about the Administrative account, not an account with admin access.) Unfortunately, Compaq and HP obscure the account on their pre-installed systems. Oops.

In order to test that the problem is grub related, I plan to recover one of the systems to factory defaults, try the converter, then reinstall Linux.

Fedora On Citrix XenServer 5

I've been having problems getting Fedora to run on Citrix XenServer 5.5.0 and have been disappointed with the resources available to complete the task. But, once again, persistence has rewarded us with victory. The problem is "an issue" with the paravirt console driver.

On the Citrix XenServer, the console is meant to redirect to /dev/xvc0 rather than tty0. With Red Hat (and Fedora's) implementation of xen, the paravirt driver intercepts tty0 and seamlessly handles the reroute. No so with Citrix, meaning we need to help the VM find the location of the console. Three changes to the VM are needed:

vi /boot/grub/grub.conf
add a kernel argument:
...xen ro console=xvc0 root=...

vi /etc/inittab
change the tty1 line:
.../sbin/mingetty xvc0

to allow root login at console:
echo xvc0 >> /etc/securetty

What might make this difficult is the fact that without these changes, you can't get to the console. Unfortunately, without the console, you can't make the changes.

The interesting thing is that you can boot to single user mode, and avoid the problem. To do this:
  1. Using XenCenter, right click the newly created VM and select Properties.
  2. Click Startup Options.
  3. For OS Boot Parameters add single.
  4. Click OK and reboot the VM.
  5. Make the changes listed above.
  6. Use the same steps to remove single from the boot params.
  7. Reboot.
This should allow you to modify the VMs configuration.

Heaven and Hell

Just needed to document this for posterity:

Heaven is where:
the chefs are Italian,
the police are British,
the lovers are French,
the mechanics are German,
and things are run by the Swiss.

Hell is where:
the chefs are British,
the police are German,
the lovers are Swiss,
the mechanics are French,
and things are run by the Itilians.

Automated YUM Update

Most Linux machines use a derivative of the YUM update utility to install software and patch systems. I've been working with virtual appliances lately and have several VMs with very low memory and disk foot prints that can't handle a full update. I'll kickstart the box, and when I try to run an up2date, the process crashes for lack of space.

Here's a little script to solve the problem:

for J in `echo {a..z}`; do echo "Doing $J..."; \
yum update -y "$J*"; yum clean packages; done

It cycles through letters a to z, updates that letter and its dependencies, then removes the downloads. Once its finished, its best to run the full update command to grab packages that start with numbers... and that notorious piece of crap NetworkManager, which starts with a cap.

Oh, and I don't care that this technique is slow.