Tether: vsphere guest operations support

[hickeng]

There is a mechanism available in guest tools called "guest operations" - this causes a process to be executed within the guestOS. This implies there is a mechanism of some kind available to trigger operations within the guest as I refuse to believe vmtoolsd polls continuously.

I suspect this is related to #406 and #407, but regardless this is necessary for picking up reconfigure operations within the containerVMs.

[dougm]

I have this working (in sloppyjoe.go form) where we can receive RPC calls from the vmx. There's a few RPCs we need to support before its possible to run in-guest commands: reset, ping, set option, get tools status, etc. With proper responses to these RPCs in place to make the vmx happy, I can use the API to trigger a start-program RPC in guest like so:

govc guest.start -vm dougm-ubuntu-1604 -l user:pass -C /tmp -e FOO=bar /bin/date --date=@2147483647

Within sloppyjoe.go, we are able to decode the RPC request (credentials, current directory, env vars, program path, program args) - in the case of tether we can support pseudo commands with this RPC path, to reconfigure the container VM for example.

Also have the path to report the guest IP address when requested, and heartbeat (for HA).

It is actually a "poll" on the guest side, via the backdoor (vmtoolsd does this too). I see plumbing in vmtoolsd to use a vsocket for the transport, not being used by default with 6.0 afaict. But regardless if transport is the backdoor or vsocket, the RPC messages are in the same format. So, any decode/encode we implement would apply to either transport.

I'm expecting to open a PR by tomorrow with the basic framework in decent form.

[hickeng]

@dougm awesome news doug! the only thing we're using this channel for as of TP3 is the signal delivery, so please prioritize that over other RPC responses. I was initially thinking of doing this via a read-write key that the tether would erase once the signal was delivered, and using a reload to pick it up, but if you think there's a cleaner way that doesn't involve a guestinfo key directly, then feel free.

[dougm]

I still have some testing/cleanup/doc/etc todo before opening a PR, which should be by tomorrow for sure. In the meantime, my WIP is here: master...dougm:toolbox

[mdubya66]

is this still required for tp3? @dougm @hickeng?

[dougm]

@mdubya66 spoke with @hickeng , we are calling this issue done after some more testing. In particular how the WebClient treats container VMs when our toolbox is running. Version/status reporting, guest shutdown, etc.

The actual tether integration with toolbox will start with #1267

[mdubya66]

👍

[dougm]

Have added more tests/fixes/features, a bit more todo and I'll have a PR by tomorrow. Current wip is here: master...dougm:toolbox

[dougm]

Pounded on this, ironing out a few more kinks, looking solid now. Also added support for guest power operations. And the UI no longer warns that "tools is not installed". My branch has been updated, but I'll wait to open a PR until TP3 merges are done.

[corrieb]

Hey @dougm, can this be closed?

[dougm]

@corrieb it will auto-close when PR #1431 is merged

[dougm]

I used the wrong auto-close comment syntax in 1431, closed now with that being merged.