What does "Received a stray message from ..." indicate?

[JayArr]

I see these warnings in my event log on the VDM interface. I was wondering if someone could shead some light on what causes these?

Received a stray message from http://vmware.guest name

Type: WARN

Module: SDMessageManager

Thread: TP-Processor3

Additional Message Details: (empty)

[mpryor · Accepted solution]

This means that there is an unknown virtual machine somewhere, with an active VDM agent, that has VDM configuration information telling it to report its status to the connection server. It's considered a stray message because the server doesn't have information on this machine. There are a few common causes for this message:

1. A VM configured within a VDM environment has been cloned and the original was later deleted.

2. A new VDM server has been set up at the same address as an old test server, one of the old agents is still present.

3. A VM has become 'lost' because it was explicitly (re)moved in the VC inventory, VDM 2.x will clean out the entry if the VM is deemed to no longer exist.

The warning message should contain the hostname of the machine so it should be quite easy to track down and delete or uninstall the agent.

[JayArr]

Thanks mpryor... that leaves me with some virtual machines in my persistent pool that are no longer valid machines?

I find this VDI product more and more frustrating that I don't think I'll be recommending expanding its use in our environment. It appears to be very flaky.

I do appreciate your help though - thank you.

[mpryor]

Sorry that you've had a bad experience with the product. This specific problem has caught a few administrators out before so...

I think here is as good a point as any to explain a little more of the VirtualCenter interaction with VDM 2.0/2.1. VDM uses VC for creation and deletion of VMs as well as power management, it also uses it to pass configuration information to the VDM agents running on the VMs, and keeps track them by their vmpath. For those that don't know what that is, it's depicted fairly accurately by looking at the folder structure in the "Virtual machines and templates" view in the VI client.

VDM 2.1 will happily keep track of VMs when moved between hosts,clusters,resource pools and datastores, but requires that the vmpath remains constant. Make sure to pick this path correctly the first time, if you need to change it you will either have to manually make changes to VDM's database or re-add them. You can spot when VDM has lost track of a VM by the following log message:

Not found: /my-folder1/my-datacenter/vm/my-folder2/my-folder3/my-vm1

VDM will eventually remove the VM entry if it doesn't hear back from the agent on that machine. Note that if you keep the VMs in the same place this will never be an issue, and we're aware that it can catch people off guard so improvements will be made around this area in the next major release.

Mike

---

On a related note: starting with VDM 2.1 we include the vdmexport tool, which is in the server bin directory - this allows you to do a full backup of the VDM environment (server settings, pools, entitlements) should something go wrong. Again, this tool has not been well advertised but I strongly recommend that all customers use this to do regular backups of their environment so that if data is lost (I know I've accidentally deleted the wrong VM or pool when testing) it can be restored again. Simply redirect the output to a file as below:

vdmexport >c:\daily-backup.ldif

Steps for restoring the data are included in the file header.

[JayArr]

That's a great tool. Unfortunately I learned of this two weeks too late. Monday morning before last I arrived into work and was greeted with a non-persistent pool that was 100% non-functional. Come to find out over the weekend the Virtual Center's VC service has stopped or didn't restart after a scheduled reboot - and VDM decided that the pool was no longer valid.

VM Support says there was no recovery other than to rebuild the pool from scratch. And combine this with the inability for clones to automatically join the domain, rebuilding a fifty workstation pool requires a lot of repetitive manual tasks.

So I hope I'm not sounding scorned, it's just that I've come to expect such great things from VMWare - only to be burned by a product that directly interacts with our school's students... it really makes both of us look bad. They don't know that most of the servers that are quietly running the show in our data center are gracefully moving from ESX host to host during maintenance and that I can provision new servers in less that 10 minutes... all they see is that the virtual workstations that they rely on to do their class work are unreliable and have all but given up on it... bringing in their own laptops and installing MSDN copies on their own.

And now I have 16 out of 19 users successfully logged in. 3 users are being directed to VDI workstations already in use - while I have twenty machines ready and unassigned in the pool.

[mpryor]

VM Support says there was no recovery other than to rebuild the pool from scratch \[...\] rebuilding a fifty workstation pool requires a lot of repetitive manual tasks

There are limited tools for getting VMs into pools with VDM 2.1. While it's possible to bring VMs in and out of manual pools, there's nothing official for adding VMs into persistent and non-persistent pools. We did publish a whitepaper some time ago with details for importing VMs through adding ldap entries (see the Virtual Desktop Infrastructure Documentation), but that does require you to get pretty stuck in. This is something we plan to improve upon in future releases.

And combine this with the inability for clones to automatically join the domain

Ah, sysprep... it's a fickle beast. VC 2.5 will use the standard Microsoft sysprep process on your VMs, there are various posts in the VI forums about problems here but here are a couple of quick tips:

• Make sure DHCP and DNS are functioning correctly in the subnet

• Use the fully qualified domain name in the customization spec.

• Make sure the template is not a member of a domain

And now I have 16 out of 19 users successfully logged in. 3 users are being directed to VDI workstations already in use - while I have twenty machines ready and unassigned in the pool.

This I'm very interested in, any chance you can give some more details of your environment. Are you able to turn trace logging on in the broker (warning: this will adversly affect performance of the machine) and one of the agents that more than one user is connecting to and give me a support bundle from each?

[JayArr]

There are limited tools for getting VMs into pools with VDM 2.1. While it's possible to bring VMs in and out of manual pools, there's nothing official for adding VMs into persistent and non-persistent pools. We did publish a whitepaper some time ago with details for importing VMs through adding ldap entries (see the Virtual Desktop Infrastructure Documentation), but that does require you to get pretty stuck in. This is something we plan to improve upon in future releases. I found that same thing, but had to make a choice between going down that path or just cutting my losses now and start with a new pool. I chose neither and just joined the vms to individual VDM connections. Then we ran into a problem where we ran out of workstations that used to be in defunct nonpersistent pool, so I decided going with enough workstations in a persistent pool would actually server our students better.

And combine this with the inability for clones to automatically join the domain

Ah, sysprep... it's a fickle beast. VC 2.5 will use the standard Microsoft sysprep process on your VMs, there are various posts in the VI forums about problems here but here are a couple of quick tips:

• Make sure DHCP and DNS are functioning correctly in the subnet

• Use the fully qualified domain name in the customization spec.

• Make sure the template is not a member of a domain

These are good tips, I'll double check our template and ensure the answer file is populated correctly.

And now I have 16 out of 19 users successfully logged in. 3 users are being directed to VDI workstations already in use - while I have twenty machines ready and unassigned in the pool.

This I'm very interested in, any chance you can give some more details of your environment. Are you able to turn trace logging on in the broker (warning: this will adversly affect performance of the machine) and one of the agents that more than one user is connecting to and give me a support bundle from each?

This was information from an instructor which turned out to be incorrect. Come to find out that a few of the vm's in the pool were not joined to the domain correctly. I think I may have uncovered a AD gremlin in our network. Disjoining and rejoining the machines fixed the problem. According to the VDM - it assumed everything was great because it was able to put a new user in touch with a new workstation and pass along the authentication information. After visiting the class room and seeing the problem for myself it was obvious the only problem was with the workstation itself.

I'll check sysprep more closely and see if we can get this darn thing working better.

Thanks for following up with my ranting with useful information, I greatly appreciate it... it's been an interesting week to say the least. I still say VDI/VDM is not ready for production and won't be recommending its expansion beyond our existing deployment until I see some significant improvements in workstation management and storage utilization. You guys are on the right track, but I think the software needs to bake a little longer in the development oven.