Name | Modified | Size | Downloads / 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 hasnt 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.