Virtualizing Small Business Server with Hyper-V Server 2008 R2
The challenge and reward of running SBS 2008 on Microsoft’s free Hyper-V Server platform.
The 2008 release of Small Business Server brought many changes, one of the most interesting being an option to virtualise all or part of the platform using Hyper-V, Microsoft's virtualisation platform.
Running a server as a virtual machine has several advantages. If you would otherwise have used more than one physical server, it saves space, power and hardware. Typically servers use only a small proportion of their available processing capacity, and virtualization lets you use the hardware more efficiently. Having said that, SBS does pack in several server components, including Exchange, SharePoint and Active Directory, so it already makes fuller use of the hardware than a single application box is likely to do.
Virtualization also solves one of the big issues with Small Business Server; recovering an installation to a new ma-chine after hardware loss or failure, or for upgrade. Microsoft's best-practice advice for moving Small Business Server to different hardware has always been to do a complex clean install and migration, rather than a simple restore from backup. Virtualization simplifies this, since the identical virtualized hardware is always available. If you have an up-to-date backup or export of the virtual machine, starting it on new hardware is the work of moments. Restoring a backup done from within the guest operating system is more effort, but also likely to succeed. There are other ways to take advantage of virtualization. SBS Premium comes with a license for as second instance of Windows Server 2008, which can run in a virtual machine. You can use this for additional custom applications, or for running third-party software such as Blackberry Enterprise Server without any concern about whether they might interfere with SBS. Hyper-V can also host older versions of Windows Server, as well as Linux.
If your customer has an application that only runs on Windows Server 2003, for example, you could run that up in Hyper-V. Microsoft allows you to downgrade your Premium second server to an older version of Windows, though exercising the downgrade right may involve a call to Microsoft to arrange activation.
Why not also use the second server as a Hyper-V host for SBS? Because while the license allows this, the second server with SBS 2008 Premium is not the R2 release, which has important improvements. A couple of the big changes are that dynamic VHDs perform almost as well as fixed, and hot adding and removal of drives is supported. This last feature is critical if you want to use the built-in SBS backup.
There are two ways to get Hyper-V 2008 R2. You can purchase Windows Server 2008 R2, in which case you get the full Windows Server GUI, or you can download the free Hyper-V 2008 R2 Server which is based on Server Core. Server Core is a recommended configuration for Hyper-V, since it reduces system requirements and lowers the attack surface for malware. Unfortunately it also ?complicates management.
There are a couple of reasons why you might not want to run SBS virtually. The first is that Hyper-V does not virtualize USB ports or COM ports on the host. This means you cannot receive faxes on the SBS guest, or hot-attach external USB devices such as hard drives.
More importantly, the lack of USB capability means that the built-in SBS backup cannot work as designed, since it is based on backing up to external USB drives.
For reliability reasons, Microsoft strongly recommends that the Hyper-V host is not joined to a domain that is managed solely by a guest operating system. This would create a cyclic dependency, where if you lost access to the guest you could also lose access to the host. If you have an additional physical domain controller this does not apply, but in a typical SBS setup you do not. This complicates managing the Hyper-V server, especially if it is using Server Core.
Despite these issues, virtualizing SBS is a compelling option in cases where the above factors are not critical.
Specifying the host PC
The overhead of running a server on Hyper-V is relatively small. According to Microsoft's estimates at http://msdn.microsoft.com/en-us/library/cc768536(BTS.10).aspx the CPU overhead is around 9-12%, the memory overhead is 300MB for the hypervisor, plus 32MB for the first GB of VM RAM, plus 8MB for each additional GB, the additional network latency caused by being virtual is less than 1ms and the disk overhead varies according to the type of virtual hard drive, but generally ranges from 0-10%.
A virtual hard drive (.VHD) is a single file on the host operating system, and can be dynamically expanding or fixed in size. Another option is to use pass-through, where the guest sees the entire physical disk. Pass-through can be convenient, but loses some of the benefits of virtualization since you can no longer backup or move a drive by copying the VHD.
There are a couple of VHD considerations for SBS. First, use fixed rather than dynamic drives. This is especially important with Hyper-V prior to R2, where performance of dynamic drives is poor. Second, avoid creating snapshots, which add further overhead and, more seriously, can corrupt Active Directory.
The system requirements for SBS 2008 - which start at 2Ghz x64 processor (or 1.5Ghz for multi-core), 4GB RAM and 60GB hard drive - do not change because it is virtual. However, there are some common-sense considerations. Using Hyper-V means you can do clever stuff like having multiple VHDs on a single physical drive, and re-using a single NIC (network card) for multiple VMs (Virtual Machines). It’s obvious that sharing physical resources like this impacts performance. For best performance, have a dedicated NIC for each VM, and a dedicated physical drive, or more likely RAID storage, for each VHD. That said, having two VHDs on a single physical drive is little different from having multiple partitions on a single drive: not optimal for performance, but sometimes it is fine to compromise. As ever, allocating more RAM to a server helps reduce disk activity and improve performance.
It may pay to over-specify a Hyper-V host, for the simple reason that you might want to run up additional VMs at some future date.
In summary, the starting point for a Hyper-V deployment is the same hardware and partitioning scheme you would use for a physical SBS deployment, though in Hyper-V you will use VHDs rather than partitions where there is more than one on a single drive. Next, add a drive or partition for the Hyper-V parent and make allowance for the host OS in your RAM calculations, though it is not demanding. Allow for a dedicated NIC for the Hyper-V parent, one for the SBS VM, and ideally one for each further VM, though light-use servers could share. Finally, if you intend to use the built-in SBS backup, add an internal drive for backup purposes.
Hyper-V Server 2008 R2 home page:
Virtualizing SBS 2008
The best official resource on virtual SBS 2008 is a low-fi Webcast only available to Microsoft partners:
Using Hyper-V with Windows Small Business Server 2008
A helpful Technet article:
Differences between Hyper-V and Hyper-V R2:
PowerShell Management Library for Hyper-V:
Hyper-V remote management configuration utility
A useful script for configuring remote management of server core:
Remote server administration tools for Windows 7:
Remote server administration ?tools for Vista:
The WBAdmin command:
How to backup Hyper-V VMs from the parent partition:
Installing Virtual SBS
In most respects, installing SBS on a virtual machine is no different from installing it direct. There are a few extra steps though, and a few special considerations.
The first step is to install the Hyper-V host. This is simply Windows Server with the Hyper-V role, or Hyper-V Server which has that role pre-installed. The next task is to create the virtual machine, which raises the whole question of how to manage Hyper-V, especially if you are using Server Core.
In Server Core, all you have is a command line, though there is a cut-down GUI available which you will see if you run certain applications, such as Notepad and Registry Editor. Administrators used to working with the GUI management tools will feel disoriented, though Microsoft does provide a simple menu, displayed on log-in and at any time by typing sconfig. The menu covers common tasks, including network settings, remote management, and windows updates. However, you will soon need to go beyond it.
Remote desktop works fine in server core, so once this is enabled you can access the server from another machine on the network. Using remote management tools though is more difficult, thanks to permission issues.
Almost any task can be done from the command line, if you can work out the correct command and arguments. There is a PowerShell library for Hyper-V which you can find at http://pshyperv.codeplex.com. However, PowerShell is not installed by default. You can enable PowerShell from the sconfig menu, by choosing Configure Remote Management and then Enable Windows PowerShell. You can enable other features using the command-line tool ocsetup, or its replacement, DISM. In combination with the PowerShell library for Hyper-V, you could now configure the VM for SBS.
Still, although it is worth installing the PowerShell Hyper-V library for scripting, the GUI Hyper-V tool is much easier to use. You can use this from a workstation running Windows Vista or Windows 7. The first step is to install the Remote Server Administration Tools (RSAT) for your version of Windows.
Next, configure your firewall and permissions to allow remote management. This is a complex task, made manageable by a script created by Microsoft's John Howard, on the Hyper-V team. Full instructions are given on the tool's home page at http://code.msdn.microsoft.com/HVRemote. Essentially, you have to download the script onto both your chosen client and on the Hyper-V server, then follow the steps given.
The main caveat is that for the script to work in some configurations, it has to grant remote DCOM access to an anonymous logon on the client, which is a security risk. Fortunately the script has an option to revoke that permission, so you can grant and revoke it as required. It is ironic that the complexities of Windows security result in the necessity for such an insecure setting.
Now you can run up Hyper-V manager on your client and connect to Hyper-V server, then use the New Virtual Machine wizard to set up your SBS VM. Note that this is not a case of accepting the defaults; read each step carefully and make changes as necessary. In the first step, for example, you will probably want to change the location where the VM is stored. It is convenient to make this the same folder where the first VHD will be located.
Another thing to watch for is that the wizard creates a dynamic VHD by default. You need to skip this step, choosing Attach a virtual hard disk later. Create the VHDs you need separately, and then attach them to the VM.
Take careful note of the settings for RAM and virtual processors, and allocate the number you have planned. The maximum of four virtual processors is recommended, provided you have this many cores in the host server.
Once your VM is configured, you can start it by booting from the SBS install media. There are a couple of points to watch for here too. If this is a migration from SBS 2003, you will have created an answer file that automates part of the migration. This answer file must be available when the installation boots. There is no option to do the steps manually later. One solution is to create a virtual floppy drive, copy the answer file to it, and attach it to the VM.
How do you format a virtual floppy disk, and copy a file, before you have a VM? One way is to attach it temporarily to another VM; or you can download a utility called winimage. Now you can step through the installation in the normal way. Another point to watch for is that some OEM media for SBS is BIOS-locked to a particular vendor, and the VM does not look like a machine from that vendor. In this case, it will not be possible to activate SBS. This is something to take up with the OEM and Microsoft.
The backup problem
One issue that Microsoft did not fully think through before launching SBS 2008 with an option for virtualization is backup. SBS comes with a built-in backup application that works nicely with external USB drives. Since virtual SBS does not recognize USB drives, it does not work as designed.
In mitigation, a virtual solution is inherently superior for backup and restore, because you have the option to copy VMs from the host alongside backing up from within the guests. It is still advisable to backup from within the SBS, partly for ease of restoring individual files, and partly because it ensures that backup-aware applications perform housekeeping such as truncating log files.
How can you use SBS backup without USB drives? The best solution is to reserve a large hard drive in the host for backup purposes. This need not be an expensive drive, since it will itself be backed up frequently. Create a fixed VHD on the spare drive, large enough to backup the entire SBS server, and attach it to the SBS VM. Finally, configure SBS to backup to this VHD according to your preferred schedule. This is a great solution for users, since it is easy to restore individual files using the SBS wizard.
The snag with backing up to an internal drive is that the entire server may fail, or be lost or stolen. Therefore, you need to back up this VHD regularly. It also makes sense to take advantage of Hyper-V by backing up the entire host from time to time.
In order to backup the VHD from the host, you need to detach it from the SBS VM. You can script this using the PowerShell Hyper-V library, or manually detach it using the Hyper-V manager. Note that in the SBS this looks like un-plugging an external drive, so you should either disable write caching on that drive, or use the "safe remove hardware" option first. Then you can copy the VHD to an external drive, and reattach it to the VM. You can also back up the entire Hyper-V host with its VMs using the WBAdmin command-line version of Windows Server Backup. The most reliable method is to shut down the VMs first, though this is disruptive for users. It may still be worth doing occasionally. You can also perform a live backup using VSS (Volume Shadow Services), though you must check KB 958662 to ensure that the Hyper-V VSS writer is enabled, otherwise a registry change is required. The third-party utility BackupAssist (backupassist.com/BackupAssist/tour_HyperV.html) supports Hyper-V Server and uses the built-in tools under the covers.
Note: avoid performing a backup of the host at the same time as backup is running in a guest, as this confuses VSS.