2009-08Aug-19
Installing Windows 7 on VMware Server 2.0.1
VMware Server does not yet support Windows 7, but that doesn't mean you have to wait for a new release. When creating a new virtual machine, pick either Windows Vista 32 bit or Windows Vista 64 bit instead. Downloading the ISO file from MSDN Subscriber Download, placing this file in one of the data stores and mounting the image into the virtual CD drive is the easiest way to get the setup running.
Windows starts the installation right after powering on the virtual machine. The remaining steps are pretty self-explanatory. When you are prompted to enter a key, you can skip this step. It's easier to enter the key later in Windows 7 when you have access to the MSDN Key list and simply can copy and paste the key.
After Windows 7 started, the first change should be to disable the mouse pointer shadow in Start > Control Panel > Mouse.
The next step is usually to install VMware tools. At least with Windows 7 in the 64 bit version clicking on the link in VI Web Access to activate the VMware Tools image only results in an error message: The operating system is not supported. You can activate the image manually, though. On the server that hosts VMware Server open C:\Program Files (x86)\VMware\VMware Server and copy the Windows.iso file into your data store. Then use VI Web Access to mount this ISO image.
Inside Windows 7 open the CD drive and run Setup64.EXE. Following the steps and rebooting the system enables VMware tools with the known benefits such as having better mouse support.
2009-08Aug-14
Object reference counters in VFP
Visual FoxPro maintains a reference counter for every object. Whenever a reference to an object is stored in a variable or property, the reference counter is incremented by one. When the same property or variable is filled with a different value, or when it goes of scope, Visual FoxPro decrements the counter by one. Visual FoxPro releases the object once the counter reaches zero.
The Visual FoxPro API provides two functions to manage this reference counter from C++ libraries: _ObjectReference and _ObjectRelease. To make them available to Visual FoxPro developers, I wrote a small FoxPro library called ObjRef.FLL.
The syntax is very simple. If you want to increment the object reference counter, you call the IncrementRef() function passing the object as the only parameter. The following sample creates a form and stores the reference in a local variable. Normally, the form would be released as soon as the code finishes. That is, you would see the form flash very briefly. With the call to IncrementRef you basically create a dangling reference to the form letting the form stay around even after the code returns:
* Create a form with just a local reference
Local loForm
loForm = CreateObject("Form")
loForm.Show()
* Create artificial dangling reference
Set Library To ObjRef.FLL
IncrementRef(loForm)
Similarly you can force an object to release by decrementing the reference counter. Even so the method hasn't finished yet, the form is gone:
* Create a form
Local loForm
loForm = CreateObject("Form")
loForm.Show()
* Release form
Set Library To ObjRef.FLL
DecrementRef(m.loForm)
Wait window
Playing around with object reference counters isn't something you should normally do. Visual FoxPro doesn't expect this and in some cases might respond erratically. When you, for instance, execute the following code and then type in the Command Window, Visual FoxPro either crashes or brings up error messages.
Set Library To ObjRef.FLL
DecrementRef(_Screen)
2009-08Aug-06
VMWare Server installation notes
After using VMWare for various purposes for many, many years now, I've moved my development environment to virtual machines two years ago. These are mostly Windows XP and Windows Vista clients with around 1 GB of RAM. I stored and executed them on my main development laptop. While using the laptop provided various advantages one disadvantage became more and more prevalent: Notebook hard drives simply can't deal very well with multiple requests at the same time.
Running a single virtual machine never really put too muchstress on my notebook. There was plenty of RAM (3.5 GB) and I didn't use the host OS that much when working in a virtual machine. Running two virtual machines maxed out available RAM, but was still manageable when. and that's a big when. only one of the two machines accessed the hard disk.
Suspending one machine, a virus scan, Windows swapping memory, Lookout indexing Outlook: Whenever the hard disks where spinning performance went downhill.
At the same time one advantage of using a notebook diminishes. Three years ago basically being able to take the office with me was a big plus. Since then connectivity has more and more become a commodity. Fast internet access (we used to call it high-speed internet not long ago) is available in more and more places. Fast mobile internet access such as UMTS has become downright cheep with unlimited data transfer for less than 50 Euros/Dollars a month.
Therefore I moved some of my development machines onto a new server and use a combination of VMWare Remote Client and Windows Remote Desktop to connect from the laptop to the server. The following are a few notes I took during the installation.
The mouse pointer can be a source of frustration if you move to a remote server. By default Windows displays a tiny shadow beneath the pointer. There's no doubt that this increases the discoverability experience of the mouse pointer. It seems, though, that drawing a mouse pointer with a shadow is significantly different from drawing one without shadow.
If the mouse pointer jumps around and there is a delay between moving the mouse and updating the mouse pointer, pointer shadows are most likely activated. Go to Control Panel > Mouse > Pointers and uncheck the "Enable pointer shadow" option. Sometimes this isn't sufficient and additionally you need to change the scheme to "Windows Default (System scheme)".
Installing VMWare server automatically adds VMWare to the list of exception in the Windows Firewall. Windows 2008 and later support multiple profiles, one each for public, private and domain access. It seems that VMWare only enables the public profile. If you server is connected to a private network, you can't access VMWare VI Web Access to configure the virtual machines.
To change this, open Server Manager.If Server Manager doesn't come automatically when you log onto the server, right click Computer in the Start menu and choose Manage. Expand the node Configuration > Windows Firewall with Advanced Security > Inbound Rules. Locate the "VMWare Hostd" and "VMWare Authd" rules. Open the properties dialog for each rule and on the Advanced page check the "All profiles" checkbox, or pick profiles individually.
Choosing the right client is difficult. I switched back between VMWare Remote Client and Windows Terminal Services. In between these I even experimented with using VMWare Workstation instead of VMWare Server on the server. Each of these has advantages and disadvantages:
VMWare Workstation
On the pro side: The network can be connected and disconnected right from the client. It also much easier to boot Windows into safe mode since the virtual machine appears immediately with the BIOS screen. Of course, VMWare Workstation also has more features and better hardware support.
There is one disadvantages of using VMWare, though. You always have to use Remote Desktop to connect to the server before you can run VMWare Workstation. Unfortunately, you cannot have WMWare Workstation and VMWare Server installed on the same computer.
VMWare Remote Client
Remote Client has a quite simplified interface. You can control the power for the virtual machine (reset, stop and suspend). Additionally you can disconnect CD drives, floppy disks and the audio device. USB devices connected to the client computer appear in a list, but the connect option is grayed out. The same applies to the Network symbol.
As my friend Peter Steinke pointed out to me, the easiest way to connect to a virtual machine with the Remote Client is by creating a desktop short cut to the virtual machine from within the web interface (it's the last option in the list of machine's action). There's no need to use the web interface every time you want to access a virtual machine.
The remote client has a few advantages. If you connect to a virtual machine that is powered off, it will automatically power on. That means you can minimize the number of machines that running on the server without having to use the web interface to start them manually.
The VMWare Remote Client also provides direct access to the CD drive on the client. If you want to burn a CD inside a virtual machine, you can use the CD writer on your client machine instead of having to put the CDs into the server CD drive. Nonetheless you need a good network connection, since otherwise you get errors when burning the CD.
The catch with this feature is that it only works when you launch the Remote Client as a local administrator on your client machine. If you have a desktop short cut, you can right click and pick the "Run as administrator" option. If you use the web interface to launch the Console, you have to run the browser as an administrator first. As a regular user you merely get the following error message when you attempt to connect the CD drive:
Failed to connect device to remote :
Could not connect to "D:". It is being used by another virtual machine or some other program.
Whenever you change the windows size of the Remote Client, the screen size in the virtual machine is adjusted accordingly. So you never get scrollbars and always see everything on the screen.
Sound is a disadvantage for the Remote client. With VMWare Server you can only connect audio devices that physically exist. If the server doesn't have audio (and why should a real server have audio?), you won't be able to forward audio to the client machine.
Logging onto the client is more annoying that with the other two options because you have to enter the user name and password every single time. The user name and password are supposed to be configurable with the -u and -p command line arguments in the shortcut. But I never could get those to work. No matter what I entered for the user name (user, .\user, server\user, user@server, user@127.0.0.1, .\\user, server\\user, and a variety of combinations), I always ended up with the error message:
Error opening the remote virtual machine servername:5000\8:
Login failed due to a bad username or password.
Remote Desktop
Connecting to a virtual machine with the Remote Desktop client provides the closest experience to the native desktop experience. When the client and the guest operating system are both Windows Vista or Windows 7 and the client computer is Aero compatible, you even get the Aero interface on the remote virtual machine including glass effects and three dimensional task switching.
Microsoft's Remote Desktop is also the only possibility to get audio from the remote machine onto the local machine. The play back quality is way below what you have with local access from VMWare Workstation or natively, but at least there is audio. Recording isn't possible, though.
One drawback of Remote Desktop is that you can't connect or disconnect any of the hardware. VMWare Tools provide access to some of these features from within the virtual machine, but it's far from being as convenient as in VMWare Workstation or Remote Client. You also don't have access to the power options. To suspend the machine you need to access the web interface from the client. The same is true for machines that are powered off. You first have to power on through the web interface before you can connect to a virtual machine.
There's no way to boot into safe mode or make any BIOS changes through Remote Desktop. The virtual machine must be working and properly configured for Remote Desktop to work. For anything else you need VMWare's Remote Client and the web interface (when using VMWare Server) or the VMWare Workstation interface (when using Workstation on the server).
Conclusion
Right now it seems the best approach to use VMWare Remote Client and Remote Desktop together. Remote Client is used for maintenance tasks, everything that requires access to local devices and to start up the virtual machine if it's not running. Day-to-day jobs are done in Remote Desktop.
2009-08Aug-06
Changing the TCP ports for VMWare Server 2
VMWare Server 2 has significant changes user interface-wise compared to the first version of the free VMWare Server product. The previous version (which itself is the successor of GSX server) provided access to the server and virtual machines through the VMWare Server Console. The Server Console could be replaced by Virtual Center 1.4, provided you had a license.
For the current release VMWare decided to replace these two tools with VMWare Infrastructure Web Access, the web client used in ESX server and VMWare Infrastructure 3.x. While the new interface offers additional features, it has received some bad critics due to its slowness and it's additional resource requirements on the server. On my server this adds up to 128 MB RAM.
Web-based software needs a web server to run on. VI Web Access is written in Java and runs on top of Apache Tomcat. VI Web Access increases the product complexity by a magnitude compared to Server Console. This wasn't really an issue when VI Web Access was part of VMWare Infrastructure. This product is usually deployed by dedicated administrators.
VMWare Server 2, on the other hand, targets the average small business user and even non-business usage. The number of postings on the web shows that web based software can be very difficult to manage when you can't even connect to the web application.
During the installation VMWare Server 2 prompts for two TCP ports. Port 8222 is used for http traffic, port 8333 for https traffic. In many Windows applications you can change the port after the installation as a matter of typing a new value into the options dialog. If you hoped the same would be true for VMWare Server 2, you'll be disappointed.
A number of web sites suggest that the only way to change the port is to uninstall VMWare server, scrub the hard disk and clean the registry from any trace of the product. Then reinstall with the correct ports. There is an easier solution, though.
While you still can't change the port in a single place, you only need to change the ports in a few files. For the reminder I assume you are running Windows Server 2008. For other operating systems you need to change the paths accordingly. I assume that you want to change the ports to 5000 (from 8333) for https and 5001 (from 8222) for http transmissions.
The tools you need are a file explorer (Windows Explorer will work) and a text editor (Notepad would be sufficient). First open
C:\Users\All Users\VMware\VMware Server\hostd\proxy.xml
Change the ports in the bolded values. These are right at the beginning of the file:
<ConfigRoot>
<httpPort>5001</httpPort>
<httpsPort>5000</httpsPort>
<EndpointList>
Next open
C:\Program Files (x86)\VMware\VMware Server\tomcat\
webapps\ui\jslib-1.0.122589\modules\
com.vmware.webaccess.app_1.0.0\WebAccess.properties
At the end of the file you find the following part. Change the port in the bolded line:
new Object({
login_url: "http://localhost:5001/sdk",
login_show_webservice_url: "false",
login_name: "",
login_password: ""
});
If you miss this file, you get to the login prompt, but entering a user name and password results in an error message. To update the link to the server page open
C:\Program Files (x86)\VMware\VMware Server\serverui.url
Change the file like this (there are just two lines in there):
[InternetShortcut]
URL=https://MyServer:5000/ui/
Finally, you need to update the location of the client plugin. Open
C:\Program Files (x86)\VMware\VMware Server\hostd\
docroot\client\clients.xml
Then change the port number in the following line
<downloadUrl>https://*:5000/client/VMware-viclient.exe</downloadUrl>
Those are all changes you need to make. They won't take effect until you restart VMWare server, or more precisely, the services that make up VMWare Server.
In the Start menu right click Computer and pick the "Manage" option. Navigate to the Services node (Configuration > Services on Windows 2008). Sort the list by name and restart all services whose name start with "VMWare" to be on the safe side. Now you should be able to connect to the web interface by typing the following URL into your browser:
https://MyServer:5000
replace "MyServer" with the computer name or IP address of your VMWare Server host machine. If you access your virtual machines through Terminal Services, VNC, or other clients, you're done now. Use the web interface to configure, start, stop, and suspend virtual machines.
Should you rely on the VMWare Remote Console, though, you need to know that while 8333 and 8222 are the only ports that you can configure during the setup, they aren't the only ones that VMWare uses. The Remote Console uses by default port 902 to communicate with the server.
Initially the Remote Console connects to the server using the https port. After authenticating the web server provides the client with details on how to connect to the console. To change these connection information, open the following file on the server:
C:\Users\All Users\VMware\VMware Server\config.ini
The first line is a new one that you won't find in your file. In the INI files you can specify the port the server is listening on and the port that the client uses. Both can be different if there's a firewall that translates the port:
authd.port = "5002"
authd.client.port = "5002"
I personally prefer the remote console to use a port adjacent to the Tomcat ports. I can then open up the firewall with a single port range rule instead of using multiple rules. The fewer rules the better usually.
Before the new settings take effect, you have to restart the "VMWare Authorization Service", or VMAuthdService for short.
