A very common belief about Virtual Server 2005 administration is that it requires IIS to be installed, either on the host machine itself or on the remote admin machine.
My day job has me spending lots of time testing and working with the internals of IIS, and I am also an avid user of Virtual Server 2005 since its internal pre-release beta days. So, I decided to investigate the details of this common belief and shine some light on what is going on beneath the covers.
Yes, Virtual Server is highly flexible when it comes to administration possibilities, even if the currently shipping administration tool does not provide it. Virtual Server administration can be decentralized, delegated, and does not even require a web server for remote access. I know because I wrote a commandline tool that does this. :-)
Virtual Server introduces a COM based Administration API that is accessible by Windows Script Host, native code, and managed code.
The API exposes everything related to Virtual Server such as:
I found this great diagram inside of Virtual Server documentation (Virtual Server Technical Reference\How Virtual Server Works\Architecture\Virtual Server architecture) that gives a high-level glance at the logical pieces and connection protocols. The diagram's URL is: http://www.microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/images/vs_und_01c.gif
Virtual Server 2005 ships with a native code EXE program named VSWebApp.exe which calls the native COM based API. VSWebApp.exe implements CGI/1.1 to read/parse input and provide HTML as output, so it naturally runs as a CGI executable on IIS to provide a web-based administration interface.
VSWebApp.exe is very nicely abstracted into logical layers and has no IIS-specific dependencies that I could find (the IO layer is pure CGI and abstracts the underlying platform away such that higher-level parts of the CGI do not worry about HTTP concepts like reading/writing entity body, retrieving/setting form parameters, HTML/HTTP encoding, etc).
Although I have not tried, VSWebApp.exe should run unmodified as a CGI on Apache for Windows. But, as I have alluded to earlier, you do not need a web server to administer Virtual Server. So, changing web servers is merely a exercise left to the reader. We can do one better by not needing the web server at all.
Virtual Server 2005 supports DCOM Remoting for its COM based API, and this support is registered within vssrvc.exe. This allows you to perform the aforementioned administration tasks against a remote Virtual Server by merely instantiating the COM object differently. In fact, VSWebApp.exe liberally uses this feature to "tunnel" and allow you to administer against a remote Virtual Server which does not have IIS installed.
Virtual Server 2005 introduces a simple internal security model. At a server-wide scope, you declare allow or deny ACL for a given user identity and the specified list of privileges, which include:
Basically, you give "Control" access to allow someone to be able to use/administer Virtual Server, "Change" to give someone the admin bit, and the others are the usual Read/Modify/Delete permissions securing Virtual Machine and Virtual Networks. And since Virtual Machines are just files, you can also apply NTFS ACLs on the files to get more interesting and granular combinations.
For example, you can give a user "View" privileges, so they can theoretically view any Virtual Machine registered on the system... but you can set NTFS ACLs on the VMC, VNC, and VHD files such that they can only see and run certain Virtual Machines.
By now, what I stated earlier should be clear.
For example, I exclusively run as non-administrator (i.e. just plain normal User) on all of my machines. I use my administrator account to install Virtual Server 2005, add my non-administrator user to Virtual Server with all privileges except Change, and then as non-administrator I can create/delete/view any Virtual Machine that my user identity has read/write access to the physical files that make up the Virtual Machine.