Home / Release
Name Modified Size InfoDownloads / Week
Parent folder
VMware-vMotionDetector-Windows-x86.msi 2013-04-22 265.7 kB
win_oem_vmotion.pl 2013-04-22 216 Bytes
vmGuestSessionID-nonOEM.c 2013-04-22 8.9 kB
vmGuestSessionID.c 2013-04-22 9.2 kB
LICENSE 2013-04-22 26.4 kB
oem_vmotion_detector.pl 2013-04-22 308 Bytes
oem_vmotion_readme.txt 2013-04-22 1.3 kB
VMware-vMotionDetector-Windows-x64.msi 2013-04-22 264.7 kB
oem_vmotion_detector-1.0-1.x86_64.rpm 2011-08-10 9.5 kB
Totals: 9 Items   586.3 kB 0
Run through for using the OEM vMotion Detector:
1) OEM will first run a perl script front-end -- i.e. oem_vmotion_detector.pl which will call the vmguestsessionid executable to get a initial session id, which is saved to a flat file on the VM (i.e. /var/tmp/vm_session_id.txt).
2) OEM will periodically re-run the same perl script. The executable will check to see if the initial session file exists. If the file does exist, it will then its current Session ID against the ‘saved’ session ID in the flat file. Otherwise, it will create a new Session ID flat file and start the process again.
3) If the Session ID hasn’t changed (between the current and the saved one), then OEM will be given a ‘em_result=0’ code, meaning nothing has changed.
4) However, if the Session ID has changed (between the current and the saved one), then OEM will be given a ‘em_result=1’ code, meaning the VM did vMotion. Also a em_message will be associated with the end result, so that OEM can then send out a message stating the change to those subscribed to the process. To allow for after-hour processing needs, a vMotion log file will be created/appended to with the old Session ID and the newly discovered one along with a timestamp. Also, to prevent repeated vMotion alert messages, the NEW Session ID will overwrite the flat file result.
Source: oem_vmotion_readme.txt, updated 2013-04-22