This content has been marked as final. Show 3 replies
Upon further investigation, it appears that the problem is with uttsc. It fails to notice that the VM has gone away, perhaps because vmware reverts the clone to a running snapshot within 2 seconds. Therefore, uttsc never exits, and when the user reconnects, uttsc simply reestablishes the connection to the new VM, without the vda script ever running the desktop selector (vdaselector), which is what tells the vda service to assign the VM to the user. I'm guessing I can work around this bug in uttsc by creating my own utaction (with delay) that will kill the user's Xsession, thereby killing the entire kiosk session. Hopefully Oracle will fix this bug soon, or document a better fix.
In the process of diagnosing a different problem (see Cloning process with VDI 3.4.1 and vCenter 5.0.0 I have discovered that uttsc does not hang around just because we were reverting to a snapshot of a running VM. We are now reverting to a snapshot of a powered down VM that needs to go through the powering on process, and the problem persists with uttsc not exiting when the VM is taken out from under it.
For anyone else who might be experiencing this problem, I have discovered that this is actually a new "feature" of uttsc, related to hotdesking and reconnection. It seems that Oracle did not think through all of the use cases before changing this behaviour. To restore the original behaviour server-wide, you can change the SunRay Server kiosk mode settings to pass the arguments "-H autoreconnect -U 0" (in addition to any other arguments you may want). This sets "autoreconnect" to be the default behaviour, but sets the number of autoreconnect attempts to zero. These can also be set per-pool, but not quite as easily (autoreconnect is a pool property, but "-U 0" needs to be set as a custom SunRay setting on the pool).