Document HA support

[vmware]

Document HA support

[stuclem]

vmware/vic#744 and vmware/vic#406 and in the Icebox, so moving this doc issue there too.

[stuclem]

Here's the doc snippet from the interop topic, for reinsertion once HA/FT support is restored.

---

You can apply vSphere High Availability and Fault Tolerance to both the container VMs and the virtual container host, so that containers and the virtual container host can power on or off independently of each other.

---

[stuclem]

#744 and #406 are still in the Icebox with no milestone, so leaving this one in icebox too.

[stuclem]

According to @hmahmood in vmware/vic#406 (comment), HA works, so we can update the doc to claim support.

@hmahmood is this true for 0.9? Thanks!

[stuclem]

From @hmahmood on March 15, 2017 17:5

@stuclem yes, with one bug outstanding: #4237

[stuclem]

From @hmahmood on March 15, 2017 17:8

@stuclem I don't think my PR actually made it into 0.9 actually, so I guess we can't claim HA support in 0.9.

[stuclem]

Thanks @hmahmood. Leaving this one in the 1.1 milestone, in that case.

[stuclem]

@hmahmood I have updated the support statement for High Availability as follows:

---

VMware vSphere High Availability

You can apply vSphere High Availability to clusters on which VCHs and container VMs run. If the host on which a VCH or container VMs are running goes offline, the VCH and container VMs migrate to another host in the cluster. VCHs restart on the new host immediately. Container VMs that were running before the migration must be restarted manually by using the docker run --restart command.

---

Changes are in stuclem@62658c2 and stuclem@a8e178e.

Is this accurate? What about FT? We currently state that FT is not supported on VCHs. Is this still true?

[hmahmood]

The HA statement looks accurate.

We do have some sort of FT right now, but it is independent of vSphere. Basically we restart the VCH if the main process (tether) crashes. We also restart any service process if they crash or exit. All of this is not tied into vSphere though.

[hmahmood]

Container VMs that were running before the migration must be restarted manually by using the docker run --restart command.

This does not appear to be correct. It looks we restart all VMs one by one, starting with the VCH.

[stuclem]

Thanks @hmahmood. Updated FT statement as follows:

---

vSphere Fault Tolerance: vSphere Integrated Containers does not implement vSphere Fault Tolerance. However, VCH processes that stop unexpectedly do restart automatically, independently of vSphere Fault Tolerance.

---

And the HA statement:

---

You can apply vSphere High Availability to clusters on which VCHs and container VMs run. If the host on which a VCH or container VMs are running goes offline, the VCH and container VMs migrate to another host in the cluster. VCHs restart on the new host immediately. Container VMs that were running before the migration restart one by one, after the VCH has restarted.

---

Changes are in stuclem@4f11c87.

Is this OK now?
Thanks!

[hmahmood]

@stuclem issue for vApp restart: vmware/vic#4779

This really is a bug that needs to be fixed. We don't support restarting the containers the way the vApp is doing currently. Containers can only be restarted from the docker command line.

[stuclem]

Thanks @hmahmood, I updated the statements about performing operations on the VMs directly as follows:

---

Performing Operations on VCHs and Container VMs in vSphere

• If you restart a VCH endpoint VM, it comes back up in the same state that it was in when it shut down.
• If you use DHCP on the client network, the IP address of the VCH endpoint VM might change after a restart. Use vic-machine inspect to obtain the new IP address.
• Do not manually delete a VCH vApp, the VCH endpoint VM, or container VMs. Always use vic-machine delete to delete VCHs and use Docker commands to perform operations on container VMs.
• Manually restarting container VMs, either individually or by manually restarting the VCH vApp, can result in incorrect end-times for container operations. Do not manually restart the vApp or container VMs. Always use Docker commands to perform operations on container VMs.

---