April 2008 - Posts
In my Hyper-V presentation on Wednesday, I said that USB support was one of the things that is missing from Hyper-V. That is correct - i.e. there is no ability to add USB devices as virtual hardware - but, in a conversation yesterday, Clive Watson pointed out that if you connect to a virtual machine using RDP, there is the ability to access local resources - including hard drives and smart card readers.
The way to do this is to use the Local Resources tab in the Remote Desktop Connection client options, where local devices and resources may be specified for connection:
If you click more, there is the option to select smart cards, serial ports, drives and supported plug and play devices (i.e. those that support redirection). In this case, I selected the USB hard drive that was currently plugged into my computer:
And when I connect to the virtual machine using RDP, it is listed the drive as driveletter on localmachine:
This is really a Terminal Services (presentation virtualisation) feature - rather than something in Hyper-V - and so it is true to say that there is no USB device support in Hyper-V for other access methods (e.g. from a virtual machine console) and that the RDP connection method is a workaround for occasional access. Microsoft see USB support as a desktop virtualisation feature and the only way that will change is if they see enough customer feedback to tell them that it's something we need on servers too.
Aaron Parker saw my presentation on Windows Server 2008 server core earlier this week and it got him thinking...
I said that Microsoft don't see server core as an application platform but there's no real reason why not as long as the applications you want to run don't have dependencies on components that don't exist in server core. I even suggested that, with a reduced surface attack area and less patching required, server core is a great platform for those applications that don't rely on the shell, Internet Explorer, the .NET Framework or anything else that has been removed.
I also mentioned that PowerShell doesn't run on server core because it relies on the .NET Framework.
So Aaron used SoftGrid to repackage the Microsoft .NET Framework and Windows PowerShell for server core - and it worked! He says there are a few errors, but as a proof of concept it's a great idea - and a good demonstration of how flexible application virtualisation can be.
I just wanted to say "thank you" to everyone who came along to one of our sessions at today's Community Day at the Microsoft Campus in Reading. I hope you enjoyed it - and please leave feedback on the UK User Groups website (the feedback form should be live next week).
For anyone who missed my sessions - either because you were in another one, or couldn't make it along - or even if you did make it along and you need some more information (I skipped over some content in both the sessions that I had meant to cover), then you can find the slidedecks and videos on my SkyDrive.
In the chalk and talk, we discussed a number of potential subjects for future user group meetings - I'm still not sure how that's going to work out as since Scotty's accident we are leaderless and also have no administrative access to this website to get a list of all the members. Still, I'm sure we'll find a way through! The list we came up with was as follows (in no particular order), but please leave a comment on this post if you'd like to see something else, or if you'd like to deliver a session at a future event (volunteers are welcome - indeed they are positively sought out!):
- Windows 2003 and 2008 co-existence
- PKI
- Real-world Hyper-V deployment
- iSCSI - Windows Storage Server? Build your own SAN that's affordable?
- WS08 - clustering - especially stretched
- IIS 7 - from an infrastructure perspective (owning and operating - not dev.)
- What's changed 2003-2008 (DHCP, IAS, etc.)
- Real-world experience of migrations.
- Microsoft Application Virtualization (was SoftGrid)
I look forward to seeing you at an event sometime soon.
Last night, I rebuilt my Windows Server 2008 machine at home to use the RTM build (it was running on an escrow build from a few days before it was finally released) and Hyper-V RC0. It was non-trivial because the virtual machines I had running on the server had to be recreated in order to move from the Hyper-V beta to the release candidate (which meant merging snapshots) and so it's taken me a few weeks to get around to it.
The recreation of the virtual machine configuration (but using the existing virtual hard disk) meant that Windows detected new network adapters when I started up the VM. Where I previously had a NIC called Local Area Connection using Microsoft VMBus Network Adapter I now had a NIC called Local Area Connection 2 using Microsoft VMBus Network Adapter #2. The original adapter still configured but not visible. Ordinarily, that's not a problem - the friendly name for the NIC can be edited but when I went to apply the correct TCP/IP settings, a warning was displayed that:
The IP address ipaddress you have entered for this network adapter is already assigned to another adapter Microsoft VMBus Network Adapter. Microsoft VMBus Network Adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?
That wasn't a problem for my domain controller VM, but the ISA Server VM didn't want to play ball - hardly surprising as I was messing around with the virtual network hardware in a firewall!
In a physical environment, I could have reinserted the original NIC, uninstalled the drivers, removed the NIC and then installed the new one, but that was less straightforward with my virtual hardware as the process had also involved upgrading the Hyper-V gues integration components. I tried getting Device Manager to show the original adapter using set devmgr_show_nonpresent_devices=1 start devmgmt.msc but it was still not visible (even after enabling the option to show hidden devices). Time to break out the command line utilities.
As described in Microsoft knowledge base article 269155, I ran devcon to identify the phantom device and then remove it. Interestingly, running devcon findall =net produced more results than devcon listclass net and the additional entries were the original VMBus Network Adapters.
After identifying their identifier for the NIC (e.g. VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Microsoft VMBus Network Adapter), I could use devcon to remove the device:
devcon -r remove "@VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}"
Result! devcon reported:
VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Removed
1 device(s) removed.
I repeated this for all phantom devices (and uninstalled the extra NICs that had been created but were visible, using Device Manager). I then refreshed Device Manager (scan for hardware changes), plug and play kicked in and I just had the NIC(s) that I wanted, with the original name(s). Finally, I configured TCP/IP as it had been before the Hyper-V upgrade and ISA Server jumped into life.
Just one extra point of note: the devcon package that Microsoft supplies in Microsoft knowledge base article 311272 includes versions for i386 and IA64 architectures but not x64. It worked for me on my ISA Server virtual machine, which is running 32-bit Windows Server 2003 R2, but was unable to remove the phantom device on my domain controller, which uses 64-bit Windows Server 2003 R2. I later found that devcon is one of the Support Tools on the Windows installation media (suptools.msi). After installing these, I was able to use devcon on x64 platforms too.