Microsoft Virtual Server 2005 gives network administrators an easy way to consolidate multiple servers and operating systems on one computer. Here's what you need to do to get ready to deploy it.
Microsoft's release of Virtual Server 2005 (VS2005) — a product designed to aid in server consolidations, test lab environments, and the migration of legacy applications to new hardware — is something of a milestone. In accordance with standard Microsoft operating procedure, VS2005 was released quite late, but it's been worth the wait. Here's what you need to do to get ready to use VS2005.
With VS2005, you're running multiple servers on the same hardware, so the product requirements are a little heftier than for a single Windows installation. Microsoft's VS2005 Web page provides the minimum requirements for VS2005, but they are woefully inadequate for anything useful. Microsoft recommends a 1-GHz processor (Celeron, Pentium III, Pentium 4, Xeon, Opteron, Athlon, or Duron), 256 MB of RAM (additional required for guests), and 2 GB of disk space (additional required for guests).
The actual system requirements will vary depending on what you're intending to run inside the virtual servers. For example, if you're planning to run a file/print server, you might want an additional 256 MB of RAM to be assigned to the virtual server, but you'd need to add significant storage beyond the paltry 2 GB required for VS2005 itself.
For a minimum, I recommend running VS2005 on a decently powered dual processor server with 2 GB or so of RAM. Of course, if you plan to run only minimal services, you can probably scale this down. For storage, consider putting all of your virtual machines on an expandable RAID array. This way, you can easily allocate additional storage to a virtual server that grows beyond its original parameters. Further, a RAID array (I prefer RAID 5 for pretty much everything) allows you to easily recover from a hardware failure. Remember that you're running multiple services on a single box, so reliability is key.
The host server must be running Windows Server 2003. All editions — with the exception of the Web Edition — are supported, even Windows Small Business Server 2003. Windows XP is supported as a host, but only for nonproduction deployment. Sixty-four-bit host operating systems are not supported.
VS2005's management tools are 100-percent Web-based, so installation of IIS 6 is necessary before you install VS2005. If you don't install IIS beforehand, the VS2005 installer won't proceed. This is true only if you plan to install all VS2005 components on a single server. If the administration components will reside on another server, IIS is not required on the host server.
The information above provides a quick snapshot of what you need to get VS2005 up and running successfully. If you're just testing VS2005, you might not need a lot more in-depth deployment information. However, if you're considering a production rollout with critical servers being deployed using this software, more considerable planning needs to take place.
The minimum requirements listed above don't take into consideration special needs for specific versions of Windows. For example, if you plan to deploy VS2005 on the Premium edition of Windows Small Business Server 2003, plan to have at least 512 MB of RAM on the host before you take virtual servers' RAM needs into account. The same holds true for the Datacenter edition of Windows Server 2003. Further, while VS2005 requires that the host have 2 GB of space, if you plan to deploy to the Premium or Datacenter edition, you should have at least 4 GB instead.
Next, start adding up the requirements for each virtual server that will be hosted by the VS2005 installation. Add up the RAM and disk space requirements for each one and add that to the base requirements to arrive at the real minimum system requirements for your VS2005 host server. Remember that these are minimum requirements.
As an example, suppose you plan to deploy VS2005 onto a Windows Server 2003 Standard Edition server. The server will host four virtual servers — three running Windows Server 2003 Standard and one running the Enterprise edition. One of the Standard edition servers will be a file/print server, one will be a DNS server, one a DHCP server, and the Enterprise edition server will run as a domain controller. You might anticipate that the file and print server needs the most resources. For this example, let's suppose that the three-year outlook for storage needs for this service is 120 GB.
Table A outlines the minimum requirements for this installation. Table B outlines the anticipated requirements, based on actual needs.
|Minimum requirements based on Microsoft literature|
|Reasonable requirements based on the real world|
In Tables A and B, the last line adds up all of the requirements and reflects the minimum system configuration you should anticipate for your host VS2005 server. Based on the figures in Table B, if I were provisioning a server to support these needs, I'd be looking at a system with 4 GB of RAM (the maximum supported by Windows Server 2003 Standard). Further, for the disk system, I'd provision a RAID 5 array with at least four fast 73-GB disks to provide maximum usable storage of 219 GB. Adding this hardware now is easier than upgrading the server later on and provides the ability to quickly adjust to requests. For example, I might have to add a service later on, and now I'll have a server onto which I can potentially load a new virtual server to support the new service.
One more important detail to keep in mind is that you are constrained by the limitations imposed by the host operating system. Windows Server 2003 Standard, for example, is limited to 4 GB of RAM. If you need virtual servers that use more RAM than that, you'll need to deploy VS2005 onto the Enterprise or Datacenter edition.
Further, understand that virtual servers running under VS2005 are limited to a single processor inside the virtual machine. This doesn't mean that every virtual server shares a single host processor (although they can). Instead, this means that you can't load multiprocessor services into a virtual machine. VS2005 itself makes use of multiple host processors. SMP support inside virtual servers is expected to be added to a future release of VS2005.
Finally, the Standard edition of VS2005 is limited to using four host processors, whereas the Enterprise edition can use up to 32. This is the only difference between the two products.
The VS2005 installation is very straightforward. For this article, I'm using the trial version of the VS2005 Enterprise edition, but the released version is the same. My host server is an Athlon 2100+ machine with 2 GB of RAM and a 60-GB disk. I wouldn't run this configuration in a production environment, but it's more than adequate for testing.
To start the installation, double-click setup.exe or insert the VS2005 CD into your server's CD-ROM drive. The installer will start if you have autorun enabled. The first few screens in the installer are pretty standard fare. The first screen asks if you want to install the product or look at the release notes. The second screen provides licensing details, while the third screen asks for your name, company name, and the ever-present product key. After that, the meaty part of the installation begins.
The next screen asks if you want a complete installation or a custom installation. A custom installation is useful if you plan to break up the different pieces and put them on different servers. (I'll cover the administrative tools-only installation in a future article in this series.) For example, you might run the Virtual Server Service on one server and the management tools on a different system. Or, perhaps you just want to install the remote control client on a system. For this installation, I'll install all of the VS2005 components onto a single server.
The installer then asks you to configure the management environment (Figure A). Remember that VS2005 is managed using a Web browser, so a new Web site is added to your server just for this purpose. You only need to specify on which port it should run; port 1024 is the default.
|Configure the VS2005 administrative environment|
In Figure A, notice that there's another selection to make. Basically, before you start heavily using Virtual Server 2005, you need to decide where resource filesï¿?the VHDs and ISOsï¿?will live. A VHD file is the virtual hard drive used by an instance of a virtual server; an ISO is the standard image of a CD-ROM. VS2005 can use an ISO file as a CD-ROM device. So, you could, for example, use a tool to create ISO images of any CDs you might need for virtual server deployment and store them on the VS2005 server. From there, you can point a virtual server's CD-ROM device at an ISO image instead of needing to keep CDs handy.
If, however, you decide you want to store VHDs or ISOs on a different computer, you need to take additional steps, which depend on where your administration tools resideï¿?on the VS2005 host server or on a different server. If you're using Windows XP as your host, your VHD and ISO files must reside on the XP host.
The additional steps configure constrained delegation and provide a means to pass through your credentials to different servers in order to make use of resources housed on those remote servers.
I'll discuss constrained delegation configuration later in this series. For this article, I've set VS2005 to allow the administration site to run as an authenticated user.
The VS2005 installer provides you with a very short summary and installs the product. No reboot is required after installation. One nice feature of the VS2005 installer is the complete installation summary that comes up after the installation completes (Figure B).
|The VS2005 post-installation summary|
The post-installation summary provides links to product documentation and a link to the administrative Web site, which is accessed using an administrative user's credentials.
With deployment planning and installation out of the way, the next steps for your use of VS2005 lie in creating and deploying virtual servers and in configuring and managing the administrative environment. I'll discuss both of these areas in detail in the next two parts of this series.