Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

SmartInspect with VMWare Workstation 8


#1

SI 3.3.3.72 VMWorkstation 8

I know these should work together, but I can’t seem to get it going properly.

Host is Win7 x64 running the Professional console. Client is a Win7 x64 VM running on the host. SI works well sending from applications on separate physical XP machines.

When running in the VM, I get different behaviour : for some applications, somes messages come through to the console on the host; for others, a block of messages (but not all I expect) when the application terminates, but nothing while it is running; other applications may have no message on the console. I’m not sure what the difference is in the applications other than that one that does get a few messages through does generate a lot more messages that the others.

I tried running the redistributable console in the VM, using the pipe connection, as well as TCP, and that behaves in a similar manner, that is, it seems to start logging once it has received a number of messages from an application.

It seems the same messages are received on the host console as on the local redistributable console, and that the messages only come through after a number of messages have been lost. The EnterProcess message at the beginning of the application does not get displayed, and the process is not listed in the list of processes. The LeaveProcess message does appear in the log if we have received some messages from the appplication.

I’m using the NAT networking, and have set the host to the IP address for the NAT network.

Are there any configuration parameters that should be set that I am missing ?

I don’t know if it is related, but occasionally the Professional console does miss an application running on the Host. I have to close and restart the application to get it logging.

The Host PC is an AMD Phenom 1090T with 6 processors and 16GB RAM, so it shouldn’t be underpowered.:wink:

TIA,

Sue


#2

Hello Sue,

Thanks a lot for your posting. We haven’t seen any specific issues with SmartInspect running in virtual machines and SmartInspect would behave the same as on “real” machines. Could you please provide me with the exact connection strings and/or configuration files you are using? If you are using any buffer async logging options in the protocols, could you please remove them just for testing, as this can lead to different results depending on the exact options you use? You can also email us the connection strings or configuration files if you prefer this.

Thanks,
Dennis


#3

Hi Dennis,

I decided to go back to basics and created a new test application.

Here is the contents of the .dpr. There is nothing in the form.

program TestSI150;

uses
Forms, SysUtils,
SiAuto,
sitest_main in ‘sitest_main.pas’ {Form1};

{$R *.res}

begin
Application.Initialize;

// CatiBeach is the name of the PC. It is using a WorkGroup
// Works on host and other pcs, not from VM
Si.Connections := ‘tcp(host=“catibeach”)’;

// Works on host and other PC, but not from VM
// Si.Connections := ‘tcp(host=“192.168.1.100”)’;

// this works on the host but not not the VM or other PC
// Si.Connections := ‘tcp(host=“192.168.138.1”)’;

// this works on the host and on the VM, but sends to the local console (as it should)
// Si.Connections := ‘tcp(host=“127.0.0.1”)’;

Si.Enabled := True;
SiMain.EnterProcess(‘Test Process’);
SiMain.LogDateTime('test at ',Now);
Application.MainFormOnTaskbar := True;
Application.CreateForm(TForm1, Form1);
Application.Run;
SiMain.LeaveProcess(‘Test Process’);
end.

The Network uses a modem/router to assign dynamic IP addresses to the PCs. It is 192.168.1.1.

This is the ipconfig for the Host.

C:\Users\Susan>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : Torrens
Link-local IPv6 Address . . . . . : fe80::29f2:e135:d94:3c3d%11
IPv4 Address. . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::45cc:5d8c:83d2:68fb%17
IPv4 Address. . . . . . . . . . . : 192.168.220.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::9d4e:368f:ef2e:c09%18
IPv4 Address. . . . . . . . . . . : 192.168.138.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Tunnel adapter isatap.Torrens:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : Torrens

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Tunnel adapter isatap.{D5FB6326-070D-4FC2-A7E5-EB7FECB56402}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Tunnel adapter isatap.{E72E445F-CFC5-44EC-9F19-A78CACE69D45}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

This is the ipconfig for the VM

Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation. All rights reserved.

C:\Users\Sue>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : localdomain
Link-local IPv6 Address . . . . . : fe80::659f:8a0a:9f95:c894%11
IPv4 Address. . . . . . . . . . . : 192.168.138.129
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.138.2

Tunnel adapter isatap.localdomain:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : localdomain

Tunnel adapter Local Area Connection* 11:

Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fb:3ccd:277f:3f57:757e
Link-local IPv6 Address . . . . . : fe80::3ccd:277f:3f57:757e%13
Default Gateway . . . . . . . . . : ::

I have NAT networking for the VM. The settings are
’Connect to host virtual adapter …’ is checked
’User local DHCP service …’ is checked

Subnet IP is 192.168.138.0, with 255.255.255.0 for the mask.

I did try changing some of the NAT settings, but I don’t understand them well, so may not have changed the correct setting.

I think it must be related somehow to the way the network is set up, as I can get the Pipe connection working locally in the VM, as well as tcp(), but cannot get the packets out to the host using tcp. I suspect some of the issues I was seeing are related to how I am setting connections, but as this test shows, there is more to it than that. Once I can get logs from the VM to the host I will sort out my own bugs.

At the moment, I can send to the console running on the host from another PC, but not from a VM.

Thanks for looking at this. Hopefully I’ve just made a silly error and you’ll be able to spot it.

Regards
Sue


#4

Hello Sue,

Thanks for the additional details. You mentioned that you are using NAT for the network settings of your virtual machine. This means that another, separate network is used for the network between your virtual machine and host machine. I believe one of the following IP addresses should thus be used to connect to the host machine (based on the ipconfig output you posted):

192.168.220.1

or

192.168.138.1

The easiest way to test this is to try connecting to the Console from your virtual machine via the ‘telnet’ command like this:

telnet 192.168.220.1 4228

That said, is there a specific reason to use NAT for the network? The easiest way to is usually to use a bridged network setting in order to have the virtual machine on the same network as the host machine (depending on your requirements of course).

Thanks,
Dennis


#5

Hi Dennis,

I had already tried both those IP addresses - there was a comment about the 138 address in the .dpr file.

// Works on host and other PC, but not from VM
// Si.Connections := ‘tcp(host=“192.168.1.100”)’;

// this works on the host but not not the VM or other PC
// Si.Connections := ‘tcp(host=“192.168.138.1”)’;

The 122 address did not work under any circumstances, but as that was for the VM network that was not enabled, I was not surprised.

The reason for using NAT is that I wanted the VMs to be available on the host only and not on the main network.

I have changed the networking back to bridged and SI is working as it should.

If you get a chance to look at testing SmartInspect in a VM with NAT networking, it would be nice to have it working if it is something simple to adjust.

Thanks for looking at this.

All the best,
Sue


#6

Hello Sue,

Thanks for the update. The easiest way to test the network configuration without using SmartInspect directly is to try just connecting to the Console listener port 4228 via Telnet:

telnet 4228

Which IP does the virtual machine have when you use the NAT configuration?

Thanks.


#7

Hi Dennis,

I had another go with NAT, and after installing the Telnet client (the VMs are Win7), was able to connect using the host name, the host ip address 192.168.1.100, but not the IP address associated with the NAT network.

When I reverted to the Bridged network I reset all the networking defaults. After changing to NAT after this, I can get logging going using the hostname, ie host=“Catibeach”, so all is good.

Following on your comments about the async parameters, I found that if I set async.clearondisconnect=“true”, then the console appeared not to receive the LeaveProcess message, and continued to appear as ‘running’ after it had terminated. Enabling async without the clearondisconnect did send through the LeaveProcess successfully on my small test.

So it all looks very good now. I was feeling lost not being able to get my logging through from the VMs when testing and it is now all great.

Thank you very much for your help. It seems to me now that the problems originated in changes I must have made to the VM NAT networking setup at some time in the past, and in resetting the defaults during the fault finding, the fault was corrected.

Regards
Sue


#8

Hello Sue,

Thanks for your feedback and for the detailed explanation, this might also be useful for other SmartInspect customers who have problems with VMware and the NAT settings.

Thanks again and just let us know if there’s anything else you need from us.

Regards,
Dennis