Monday, April 16, 2007
Current status
I am hungry, thirsty, tired, and I have to go to the bathroom. If this is the Sims, I will die very soon (probably after some despot builds walls around the pool).
I am so busy at work that posting here is completely irresponsible (but I need the time off). Here's the scoop. I have a slightly different job under a somewhat different management structure. That's about all the detail I have right now. EXCEPT that I have to do a bunch of crap for my old job first and then I already have a queue of stuff waiting at my new job. AND they gave me this project to make a video, which was pretty fun (if very time consuming) and then all this criticism about how I need to change this and that, so those changes are in process. I feel beaten up.
Here's my computer lesson of the day: VMRUN.EXE cannot be run from inside a guest with 100% reliability. I'm using vmrun revertToSnapshot to have the guest revert it's own snapshot. Apparently this is not a supported use case. I am going to need to bug my contacts at VMware (which, surprisingly is rather a lot, I did well at networking over there) to find out how to submit this as an enhancement request. Meanwhiles, I had to build a very rudimentary client/server architecture to have the guests send in a revert "request" to a controller that stays online.
You know, this use case seems to have escaped VMware fairly completely since I can name several operations where it would be handy for the guest to have a little more sense. I know that some people are using VMware in situations where guest knowledge of the virtualized environment is considered a vulnerability, but for software QA, this is far from the case. If my guests could get some information about the hosts, it would simplify what I do quite a bit. For instance, if there was some way to query the VM Tools about, say, the name or path of the guest, then I could write some generalized code to snapshot and revert the guests with minimal user configuration. As things stand now, it feels like a total hack the way I have to do this stuff. ANYWAY...
I am so busy at work that posting here is completely irresponsible (but I need the time off). Here's the scoop. I have a slightly different job under a somewhat different management structure. That's about all the detail I have right now. EXCEPT that I have to do a bunch of crap for my old job first and then I already have a queue of stuff waiting at my new job. AND they gave me this project to make a video, which was pretty fun (if very time consuming) and then all this criticism about how I need to change this and that, so those changes are in process. I feel beaten up.
Here's my computer lesson of the day: VMRUN.EXE cannot be run from inside a guest with 100% reliability. I'm using vmrun revertToSnapshot to have the guest revert it's own snapshot. Apparently this is not a supported use case. I am going to need to bug my contacts at VMware (which, surprisingly is rather a lot, I did well at networking over there) to find out how to submit this as an enhancement request. Meanwhiles, I had to build a very rudimentary client/server architecture to have the guests send in a revert "request" to a controller that stays online.
You know, this use case seems to have escaped VMware fairly completely since I can name several operations where it would be handy for the guest to have a little more sense. I know that some people are using VMware in situations where guest knowledge of the virtualized environment is considered a vulnerability, but for software QA, this is far from the case. If my guests could get some information about the hosts, it would simplify what I do quite a bit. For instance, if there was some way to query the VM Tools about, say, the name or path of the guest, then I could write some generalized code to snapshot and revert the guests with minimal user configuration. As things stand now, it feels like a total hack the way I have to do this stuff. ANYWAY...
# posted by James Tatum @ 9:53 PM 
