The Windows Server Performance team show how to increase network throughput to guest VMs on Hyper-V. Linking here for Future-Howard, who will certainly need it again.
Some time ago I posted at length about Sony’s decision to disable the Virtualization Technology features of the Intel chips in their high-end laptops, namely my Vaio Z11.
Well thanks to the sterling efforts of one man and his EFI hacking skills, we now have a solution as this image demonstrates. The image on the left shows the result of the VMWare Virtualization Technology test CD confirming that VT is now enabled on my Vaio Z11.
I’ve mirrored his code and instructions here in case his site disappears, read more after the jump…
Update 30th July 2009: See this post for details of a confirmed VT fix for the Z11. I’m using it now!
I love my Sony Vaio Z. It’s a wonderful bit of kit – exactly the power/portability ratio I wanted. It has enough grunt to play the odd game in “Speed” mode while giving 6 hours of battery life on wireless in stamina mode. Not to mention to gorgeous 1600×900 LED screen and the built in 3G wireless.
I have one problem with it and it’s a failing of Sony’s decision making rather than any particular problem with the kit. Sony disable the Intel Virtualization Technology in the Core 2 Duo on all their Vaio machines. I’ve seen no valid rationale for this other than “We don’t support VT on the Vaio range.” This is absurd since all the Core 2 Duo chips feature Intel Virtualization Technology and I can’t imagine how having it switched on would adversely affect Vista or XP (the two Operating Systems Sony officially supports).
If this were a consumer laptop I could understand – but it’s specifically targeted at business users. In my business I make extensive use of both Microsoft and VMWare’s virtualisation systems – both of which run much faster on hardware that has the VT functionality enabled. There are a good number of people on various forums spitting blood about this issue so I’m not the only one complaining.
There is light, of sorts, at the end of this tunnel. Since Sony have done this before on other machiens in the Vaio series, people have managed to re-enable VT by using BIOS editing tools to flip the right register. Unfortunately it requires intimate knowledge of the BIOS – knowledge that we won’t have until Sony release a BIOS update that can be reverse engineered. If we’re very lucky Sony will make amends by releasing a BIOS update that allows us to enable VT in the BIOS interface proper.
The worst part of this is that we (Vaio Z owners) didn’t know that VT was disabled until after we bought the machines. I know a number of people have returned their units and bought Toshiba or Dell machines that haven’t been crippled by the vendors. Sony advertised a Core 2 Duo Mobile processor, they didn’t mention in any literature that they’d be disabling bits of the processor for no reason.
Sony, if you’re reading this – please give us control over the entire processor and let us enable VT.
I’m looking for help here.
The image you see here is a screen capture of one of my virtual machines suffering some form of graphic corruption. It should look like this. This happens often enough now that it is seriously irritating. I can make it go away by closing VMRC and reconnecting to the server, but I’d rather not have to do so several times a day (sometimes multiple times an hour).
I’m running Virtual Server 1.1.603.0 EE R2 SP1, and all my VMs have Virtual Addition version 13.813 installed. The VMRC client which came with R2 SP1 is version 1.1.603.0.
The same corruption is visible from machines with ATI and NVidia graphics cards, running XP SP2, Vista or Server 2003.
So – why is this happening, and how can I stop it?
This was a weird one. I’ve just built the new x64-based VM server, and moved a number of my VMs onto it for testing. A few of those VMs run under a local (to the host) service account so they can be automagically started by the server. For some reason, the VMs which had been set up like this couldn’t see the External network. I reinstalled the VM Additions, removed and reinstalled the NIC in the Guest and generally scratched my head because this same setup worked just fine when it was a 32-bit box and it was exactly the same… wasn’t it?
Well no, actually, it wasn’t. Turns out the user I’d created for launching the VMs on the x64 box wasn’t exactly the same as the user on the old box. It wasn’t a member of the Administrators group. So note to self: if you want them to be able to access the NIC, start your VMs in a user context that has Admin rights. I’m sure with a bit of testing I could find the URAs that would lock this down with a little more granularity, but the Administrator right blanket fits for now!