-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document vMotion support #818
Comments
Requires updates in the topic on vSphere interop. The descriptions of #859 and #858 list what will be supported once those issues are implemented. |
We currently say the following in the topic on vSphere interop: vSphere High Availability, Fault Tolerance, and vSphere vMotionIT teams can assure service-level agreements for container workloads with VMware vSphere Distributed Resource Scheduler as well as reduce planned and unplanned downtime with VMware vSphere High Availability and VMware vSphere vMotion. 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. You can also restart or upgrade the virtual container host without needing to take the containers offline during the process. You do not require a native agent on the ESXi host. The appliance VM does not need to be running for vMotion to occur. Clusters with non-container VMs can also vMotion with fully automated DRS. NOTE: In the current builds of vSphere Integrated Containers Engine, support for HA, Fault Tolerance, and vMotion is not yet fully implemented. @mhagen-vmware and @hickeng is this OK? |
I might move that note to the top actually, as some people might stop reading at some point and not see that we don't actually work at all, but otherwise the language sounds fine. |
Done! Thanks @mhagen-vmware. |
Document vMotion support, as defined in #770.
The text was updated successfully, but these errors were encountered: