About
You arrived at the weblog of Geert Baeke. I am a technology consultant for a company called Xylos (Belgium). I mostly work with Microsoft technologies such as Windows, Active Directory, Exchange, Sharepoint, MSCS, and more. I am also actively busy with VMware's products, focussing on VMware ESX.

Search





Sections
Networking
View Geert Baeke's profile on LinkedIn

Services

RSS Newsfeeds
baeke.info Main RSS Feed Main Page RSS
Virtual Machines RSS Feed Virtual Machines RSS
XBOX 360
View Article  Using the VMWare COM API from .NET

When you start writing your own programs to interact with GSX or ESX server, you might want to do so from a .NET application. In this article, I will show you how to do just that. It is quite simple.

In this example, I will build a simple application that illustrates how to perform the basic tasks. The application just retrieves a list of registered virtual machines and displays them in a listbox. When you double click the virtual machine, some details about that virtual machine are shown.

The sample was developed with Visual C# 2005 Express Edition.

1. Install VMWare COM API
You need to install the VMWare COM API on your system. You can install the COM API using VMWare’s installer or you can just copy the following files to a directory on your system (available when you installed the COM API on another machine, such as the GSX server itself):

VmCOM.dll
VMControlLib.dll
libeay32.dll
ssleay32.dll

Register VmCOM.dll with regsvr32 vmcom.dll.

2. Start a new project and add a reference to VmCOM.dll
In Visual C# 2005, start a new Windows Application project.  In the Solution Explorer, right click your project and select Add Reference.

Ref

Select the VMWare VmCOM 1.0 Type Library and click OK.

3. Use the VMWare COM API in your code
Add a using statement to your code:

using VMCOMLib;

To connect to a VMWare server, first create a VMConnectParams object:

vmConn = newVmConnectParams();
vmConn.Hostname =
"server";
vmConn.Username =
"user";
vmConn.Password =
"password";

To connect to the server with these credentials:

vmSrvCtl = newVmServerCtl();
vmSrvCtl.Connect(vmConn);

Now you are connected to the server, you can enumerate the registered virtual machines:

foreach (string s in vmSrvCtl.RegisteredVmNames)
{   VmCtl vm = newVmCtl();  //create object to control a virtual machine
   vm.Connect(vmConn, s); //connect to virtual machine
   listBox1.Items.Add(
newvirtualMachine(s, vm.get_Config("DisplayName")));
}

In the code snippet above, I add a virtualMachine object to a listbox. The virtualMachine class is just a custom class I use to store the path to the vmx file and the displayname of the virtual machine in each listbox item. The class has an overridden ToString() method to show the displayname of the virtual machine in the listbox.

Now you can add some code to display information about the virtual machine when you double click that machine in the listbox:

virtualMachine vmItem = (virtualMachine)listBox1.SelectedItem;string vmx = vmItem.vmx;VmCtl vm = newVmCtl();
vm.Connect(vmConn, vmx);StringBuilder sb = newStringBuilder();
//ip seems to be the only out of the box guestinfo variable
sb.AppendFormat("Name:\t {0}\n", vm.get_Config("DisplayName"));
sb.AppendFormat(
"Memory:\t {0}\n", vm.get_Config("memsize"));
sb.AppendFormat(
"IP:\t {0}\n", vm.get_GuestInfo("ip"));
MessageBox.Show(sb.ToString(), "VM Details", MessageBoxButtons.OK, MessageBoxIcon.Information);

The above code is used in the DoubleClick event of the listbox. It just gets the vmx name from the currently selected item in the listbox and then connects to the virtual machine with the VmCtl object. You always connect to a registered virtual machine using the full path of the vmx file (configuration file) of that virtual machine. Once you are connected to the virtual machine you can do things such as starting and stopping or just retrieving information.

In the above example, I only retrieve information from the vm. When you use get_Config, you retrieve information from the vmx (such as displayName and memsize). When you use get_GuestInfo, you retrieve information you have set with the VMWare Tools. Apparantly, ip is an available GuestInfo variable that retrieves the ip address of the virtual machine. It seems there are no other such variables.

File Attachment: GSXdotNET.zip (50 KB)

View Article  More issues with the shared folders feature in VMWare

In an earlier post, I talked about an issue in VMWare when you try to create a trust from a Windows 2003 SP1 domain controller virtual machine. That virtual machine ran in GSX 3.1. I upgraded GSX to version 3.2 but the problem remains.

There is another issue with the Shared Folders feature when combined with terminal services. This issue is documented by VMWare in their knowledge base. The solution offered by the knowledge base is to remove hgfs (driver for the shared folders feature) from the following registry value.

HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

A reboot is required after this change.

The solution that is offered by this knowledge base article does not solve the trust issue. The trust issue is only resolved when the shared folders feature is completely removed.

Because of these issues, I advise customers not to install the Shared Folders feature in GSX and ESX environments. The feature cannot be used with ESX and GSX anyway. When you install the VMWare Tools, choose Typical instead of Complete. A typical install does not include the Shared Folders feature.

View Article  Problem copying large files between VMWare guest and host

When you copy a large file between a VMWare guest and the host, you might get the following error in the guest:

Error_in_guest

On the host, you will see the following event:

Eventlogerror

It is very annoying and is not so easily solved. The reason why this happens is explained in the VMWare knowledge base. This web page also contains more info. In essence, it happens because of a security feature in Windows 2003. Windows 2003 thinks a denial of service attack is happening because the transfer rate is higher than possible. The solutions are discussed in the VMWare KB article.

View Article  Problems creating a trust in a VMWare environment

In a test environment running in VMWare GSX 3.1 on a Windows 2003 host, we had problems creating a trust between two domains. The Windows 2003 domain controllers are SP1 running as VMs. I will tell you up front that the problem was caused by the fact that the domain controllers run as virtual machines with the VMWare Tools installed!

The following setup:

  • Domain A: Windows 2000 domain controllers, native
  • Domain B: Windows 2003 SP1 domain controllers, native
  • DNS and WINS name resolution fully functional and verified
  • You want a trust from domain B (2003 SP1) to domain A (could be any version)

When you try to create the trust with Active Directory Domains and Trusts on one of the Windows 2003 SP1 domain controllers (domain B), you will get an error about not being able to contact the domain controller in the trusted domain A. The error is shown directly after you specify the name of domain A.

You can create the trust with netdom.exe because you can specify credentials for both domains. However, verification of the trust using Active Directory and Trusts will fail. The trust will work though!

Under the hood, when you create a trust using the trust wizard, the Windows 2003 domain controller will first try to connect to the trusted domain's domain controller using the credentials from the trusting domain (domainB\administrator). Logically, that will fail (because there is no trust). However, after that failure, a null session should be setup so that the Windows 2003 domain controller can talk to the LSA using RPCs. The null session is setup by connecting to \\targetdcindomainA\ipc$ using null as user and password.

In our environment, the null session was not setup at all. After the wizard tries to connect with domainB\administrator and the (obvious ) error STATUS_LOGON_FAILURE as seen in a network trace, the process just stops. No null session is established, not even tried! And the trust wizard throws the error.

SOLUTION
Remove the Shared Folders feature of the VMWare Tools. That feature uses a driver, hgfs.sys, that apparently causes this behaviour. After I removed that driver, everything functioned normally. The null session was established and the trust wizard continued without issues. Verification of the trust afterwards is ok as well.

On some of my virtual machines, hgfs.sys was still loaded after removing the VMWare Tools. Manually check that the driver is not loaded.

This is not really an issue with virtualization. It is, quite simply, a driver issue. In production, I would recommend against using the shared folders feature.

NOTE
You should use VMWare GSX 3.2 with Windows Server 2003 SP1 virtual machines. I have not yet checked if GSX 3.2 solves these issues.

View Article  Simple perl script to disconnect all floppies and cd-roms from virtual machines on GSX

VMWare GSX comes with a VmCom and VmPerl scripting API to script actions you need to perform on GSX. You can use the scripting API to get a list of all registered VMs, get their execution state, get configuration parameters and so on.

I needed a script to disconnect all floppies and cd-roms from all virtual machines on a server. The scripting API makes this simple.

Check the attached file for a sample Perl script that does the trick. It is best to add the directory where VMWare GSX installed Perl to your path. Normally, Perl is installed in C:\Program Files\VMware\VMware VmPerl Scripting API. You should also connect the .pl extension to C:\Program Files\VMware\VMware VmPerl Scripting API\perl.exe.

To run the script (after path change and .pl extension), just type disconnect.pl from the command prompt.

Of course, you can create a similar script with VBScript or JScript but what's the fun in that.

1 Attachments

 

Login
User name:
Password:
Remember me 
This Month
January 2006
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
Powered by BlogHarbor
Powered by BlogHarbor
StatCounter