Container backed hosts in simulator #3177

Refactors the container logic out of the simulator VM file so it can be used for both VM and host container backings. The following file structure is now in place: * container.go - wraps docker operation execs * container_virtual_machine.go - orchestration of containers for VMs * container_host_system.go - orchestration of containers for Hosts * container_xxx_test.go - test for container backed VMs/Hosts Add CGO_ENABLED=1 to test command with -race

This adds support for backing a host with a container in a similar manner to how we back VMs with containers. Hosts do not have the VM ExtraConfig mechanism, and "creation" of a host is more "register the existance of" vs VMs that are actively constructed from the provided spec. As such, this uses the advanced options mechanism provided by the per-host Option Manager instead of ExtraConfig, but following the same "RUN.container" key/value approach for defining a container backing. The created container for a host has the following volumes defined: * bootbank (read-only) * altbootbank (read-only) * OS-DATA (read-write) * datastore1 (read-write) The volumes have suitably formed UUIDs, are mounted under /vmfs/volumes, and have symlinked pretty names. The volumes are associated with the host via labels, allowing the use of filtered queries to retrieve volumes associated with a given host. All docker invocation is kept in container.go and out of the container_xxx.go files. Not clear this is a fundamental benefit, but should make it easier if we ever want to support remote docker hosts.

Creates an OptionManager instance per-host, with valued seeded from the ESX template but not directly referencing it, ie. template changes will not reflect into existing OptionManager instances. OptionManager Query and Update methods work as expected. Changes made via OptionManager are reflected into host.Config.Options array, but it's a unidirectional reflection. This is done to match infered behaviour of ESX. There are two OptionManager instances for ESX (and I assume for VC), For ESX they are found at: * ServiceContent.setting * ConfigManager.advancedOptions The settings for ESX are empty, and the template had named the adv opts as settings. This adds an empty Setting array in the templates to clearly differentiate which set of BaseOptionValues is used to populate which OptionManager instance. Follow up required for: * VC to determine what the contents of adv opts should be. * whether HostConfigInfo.Options is adv opts, or combined set

Connects sim-hosts to bridges as specified in their config. The bridges to use for a given pNIC are expressed in the advanced options using the following pattern (example for pNIC 0): RUN.underlay.vmnic0=vcsim-mgmt-underlay This uses an existing bridge or creates a new one as needed. If a host has a container backing, all pNICs defined in the host template are discarded and new pNICs are created, 1 per underlay name provided to simulator.HostSystem.configureContainerBacking. This was the only sane way I found to indicate which bridges a host should be connected to. The IP assigned to the container is reflected into the various host.Config structures associated with the vmknic, eg. VirtualNicManagerInfo The simulator.HostSystem.getNetConfigInterface method is prvoided to allow a caller to retrieve all the various network entities associated with a NetConfig binding, eg. "management", "vmotion". Remove use of errors.Join to maintain support for older Go versions. Known issues: * podman volume ls filters act as OR instead of AND which results in all volumes being deleted any time a single host is removed. Issue opened and fixed in podman main.

If "RUN.container" is added or removed on an existing VM, that change is applied immediately if the VM is currently powered on. Modifications to the value of the key do not have an effect unless the continue needs to be recreated for some reason. Switches to Go templates for formating docker command output Includes additional error logging detail

Makes use of the docker events stream to trigger inspect operations against containers where waiting for things such as IPs. Corrects prior failure to stop the async container watch when the container was removed. Updates to locking to avoid race warnings. Updates vcsim.bats to look for a volume with `--dmi` suffix instead of a volume with the plain container name.

Adds a stage to the github actions pipeline that provides an ssh server that allows interactive login to the environment. This only triggers on failure. The reason for adding this is due to repeated failures to find functional arguements for the specific docker version present. Quirks around the format parameter values specifically. This is done using the tmate action: https://github.com/mxschmitt/action-tmate Corrects boilerplate

I expect to squash this into an earlier commit once it passes tests vcsim: support container backing for hosts

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Container backed hosts in simulator #3177

Container backed hosts in simulator #3177

Commits on Aug 7, 2023