Over Christmas I completed migrating our SCVMM 07 environmentover to SCVMM 08. An issue appeared this week which had me stumped, all of a sudden creating VMs from some templates started to fail when trying to “Install VM Components”.

Error (3101)
VMM failed to mount VHD file D:\BOH-DHOPE-V07\BOH-DHOPE-V07_disk_1.vhd on the * server. A timeout occurred.
(Internal error code: 0x80990C1D)

Recommended Action
Check Device Manager/System Devices to make sure that Microsoft Virtual Server Storage Bus is installed and functional. If it is not, install VHDMount component of Virtual Server. Restart Virtual Disk Service, and then try the operation again.

This had started occurring on all our hosts where Virtual Server 2005 had been upgraded as part of the SCVMM 08 migration. Servers which didn’t need the Virtual Server 2005 update didn’t have this problem.

Setting VHD_MOUNT_TRACE=2 and trying to mount the VHD led to the following error:
The specified operation could not be completed as an unexpected error has occurred.

The workaround is to stop the Virtual Server service, uninstall Virtual Server and install again (from the ‘vs’ folder from SCVMM 08).

As you may have heard, all 30Gb Zune’s refused to work on December 31st 2008 due to a bug in the internal clock driver related to the way the device handles a leap year.

Somehow, the sourcecode to the RTC clock driver code has appeared on the internet. The code itself was written by Freescale Semiconductor though, not Microsoft.

The problematic code seems to start on line 249:

//------------------------------------------------------------------------------
//
// Function: ConvertDays
//
// Local helper function that split total days since Jan 1, ORIGINYEAR into
// year, month and day
//
// Parameters:
//
// Returns:
// Returns TRUE if successful, otherwise returns FALSE.
//
//------------------------------------------------------------------------------
BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)
{
int dayofweek, month, year;
UINT8 *month_tab;

//Calculate current day of the week
dayofweek = GetDayOfWeek(days);

year = ORIGINYEAR;

while (days > 365)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}

// Determine whether it is a leap year
month_tab = (UINT8 *)((IsLeapYear(year))? monthtable_leap : monthtable);

for (month=0; month<12; month++) { if (days <= month_tab[month]) break; days -= month_tab[month]; }
month += 1;

lpTime->wDay = days;
lpTime->wDayOfWeek = dayofweek;
lpTime->wMonth = month;
lpTime->wYear = year;

return TRUE;
}


Basically, December 31st was being qualified as a day > 365 (Which is correct, it was day 366 as 2008 was a leap year). The bug is that the code only checks for days > 366, not = 366. The poor Zune’s were getting stuck in the while loop until January 1st when they could finally break out.

For the last month or so my ISP, British Telecom, have been limiting BitTorrent download speeds (upload speeds have remained unaffected).

When I signed up with them I quizzed their sales people about what traffic shaping technology they employed and whether they used bitfield mangling or similar technologies. They said no, it was a truly unlimited service. Despite numerous calls to their support department (who aren’t technical and just ask you to reset your router) I’ve given up the battle of getting them to at least confirm what they’re doing.

Without any workarounds on my end, torrent downloads were limited to about 55kb/s – A real pain if you’re trying to download some of Simon’s VMWare images.

Thankfully it turned out to be quite simple to get around BT’s traffic shaping system. Enabling RC4 encryption on all the torrent connections was sufficient to up my download speed to about 800kb/s. RC4 not only encrypts the headers but the entire data stream. The only downside is that it requires more CPU time to decrypt the traffic.

Assuming you’re using Vuze (formally Azureus), here are the simple steps you need to take:

1. Go to: Vuze > Preferences.
2. Expand Connection > Transport Encryption.
3. Check “Require encrypted transport”.
4. Set the “Minimum encryption level” dropdown to RC4.
5. Tick the “Allow non-encrypted outgoing connections” checkbox (to enable compatibility with peers not supporting encryption).
6. Tick the “Allow non-encrypted incoming connections” checkbox.

After a minute or so your transfer speeds should jump to about 600kb/s. The ball’s back in your court, BT.