We used the New option in the SM actions panel to launch the New Virtual Machine wizard, which created our VM and provided some configuration options. For example, the wizard let us configure the VM to install an operating system from an ISO image of the installation CD for IPCop. The wizard wouldn't let us configure our VM with Legacy NICs, so we created the VM without NICs and then used the actions panel to edit its settings to add two Legacy NICs, one connected to the internal VM network, the other to the external VM network.
Legacy NICs emulate a popular DEC NIC, and can be used by just about any operating system that has a driver for this card. 'Enlightened' operating systems can use more efficient non-legacy, or enlightened-mode NICs, provided that a suitable 'driver' is available for that OS. Currently Microsoft supplies such drivers for Windows Vista, Windows Server 2008 and Windows Server 2003. The drivers are supplied as part of the Integration Services Suite, which must be installed in a VM separately after the VM OS has been installed.
Installing the IPCop Linux-based firewall on a new virtual machine.
With the VM created we could right-click on it in the central SM panel to get a drop-down menu, and then click on the 'Connect...' option. This opened a window onto our VM, complete with control buttons to start, stop and pause it, and to provide a screen display. We used the Start button to boot this VM, and watched the screen display as it loaded the IPCop installation software.
Unticking the TCP/IP v4 and v6 bindings from the server's physical NIC prevents Windows Server 2008 from accessing it, allowing a broadband modem to assign a public IP address to a Linux firewall VM via DHCP.
During the IPCop installation we assigned a static class C address to the 'internal' VM NIC. This would be the LAN address of the firewall. We configured the other VM NIC to obtain its address using DHCP. This NIC was connected to the external virtual network, which was in turn connected to our broadband modem. The broadband modem would assign our public IP address to the firewall using DHCP. However, for this to happen reliably we also needed to prevent our Windows Server 2008 system from using the physical NIC, which we did by removing (unticking) the TCP/IP v4 and v6 bindings from the NIC using the Windows Control Panel. Finally we configured our Linux firewall as a DHCP server to provide LAN IP addresses to computers attached to the internal network.
The end result was a VM running Linux firewall software that would provide LAN IP addresses to our host server and to any of its VMs, provided these systems were configured to use the internal virtual network and to use DHCP. The host server and its VMs would connect to the internet via the Linux firewall. Had we used a 'private' network instead of an 'internal' one, our setup would have allowed a number of VMs to run inside an extremely secure DMZ, protected by the VM running Linux firewall software from network traffic from the LAN and the host server. This configuration would have required a second NIC to be fitted in the host server so that it could access the LAN.
During our tests the Windows Control Panel reported four CPUs and 3GB of RAM fitted in our system, regardless of the CPU and RAM requirements of the VMs it was running. This suggests that Windows Server 2008 rather than Hyper-V was managing the hardware used by virtual machines. This is in contrast to VMware ESX Server, where the Linux-based console operating system normally reports one CPU and around 512MB of RAM, even though the server hardware could be configured with, for example, four CPUs and 3GB of RAM. With ESX Server, the VMware hypervisor, rather than the console operating system, is clearly managing the CPUs and RAM used by the VMs. The Hyper-V architecture also runs a stack of virtualisation software, including the VMBus used by all the VMs, in the parent Windows Server 2008 partition. This means that all VMs on a server could be badly affected if the parent partition crashed or became unusable because some software consumed too many resources.
We tested this by making our host server run a memory benchmark configured to 'realtime' process priority in Task Manager. In this test, it took over 32.1 seconds for a Vista VM to launch Internet Explorer and open Google, compared to 2.5 seconds when the server was not running such a workload. Again, this is in contrast to the VMware architecture, where a problem with the console operating system is unlikely to affect all the VMs hosted by the hypervisor. Our test results lead us to recommend running only the barest minimum amount of software in the host Windows Server 2008 environment.
In our tests on a quad-core workstation, we found that Hyper-V could allocate four virtual processors to its VMs. And as it stands, this first version of Hyper-V does not make USB devices available to VMs. In addition, we could not drag and drop files from the host Windows Server GUI onto the desktops of VMs running Windows. However, Hyper-V will automatically pause and resume VMs when the host server is started or shut down. All this in line with what you'd expect from VMware ESX Server. However, VMware's desktop virtualisation product, Workstation 6, enables VMs to use USB devices and allows files to be dragged from the host PC's desktop and dropped onto the desktop of a VM running Windows.
6%
3%
