Closed stuclem closed 7 years ago
Partial implementation of #701 is in https://github.com/vmware/vic/pull/2283.
PR https://github.com/vmware/vic/pull/2283 is merged.
According to @hmahmood via Slack, despite PR #2283 we are not yet ready to claim support for VCH restart, so moving this back to backlog.
Some info about restart that was posted on Slack on 12th October:
Ryan Kelly [2:36 AM]
How do I auto start a container in vIC if the virtual container host is rebooted?
Emma Lin [4:19 AM]
@rkelly if vch is rebooted, the container is not affected
[4:19]
if it’s started before vch is rebooted, it’s still alive
Massimo Re Ferre [11:50 AM]
@emma I think you are referring to the virtual container host vm proxy whereas @rkelly may be referring to the virtual container host “as a whole” (i.e. the vApp). That is… if I shutdown the vApp and start it again (or if I reboot/reset it for that matter)… do the containerVMs that were running inside the VCH starts up automatically?
George Hicken [1:16 PM]
@mreferre @rkelly @sclements If the vApp is explicitly shut down as a whole, then the containerVMs will be shut down as well. If you chose shutdown (instead of power off) then the containerVMs should shut down via STOPSIGNAL and a clean shutdown path. https://github.com/vmware/vic/issues/744 is to support --restart
, via HA config and the vApp config
Network persistence is tracked by https://github.com/vmware/vic/issues/2448, implemented in PR https://github.com/vmware/vic/pull/2771.
Not required for 0.7, so moving back to backlog.
@hmahmood, I see that the Epic for restarting the VCH (https://github.com/vmware/vic/issues/701) is now in the icebox. I assume that when you restart a VCH is doesn't quite come back the same as it was previously. In terms of documentation, we need to write up what is and what is not persisted when you restart the VCH. What are the limitations that we need to document? Thanks!
The only outstanding issue in that epic is #482. @fdawg4l can you comment on what exactly is broken with VCH restart if #482 is not fixed?
@hmahmood there is a currently a workaround in place for #482 which keeps track of the relationships we'd like the infrastructure to maintain. This epic should be functional without #482 because the workaround exists and we're leveraging it.
I think that issue talk about "restarting the VCH" meaning two completely different things.
There is the restart of the complete VCH (i.e. the entire vApp which includes the VCH Docker EndPoint VM and ALL containerVMs) and what happens there (tracked in https://github.com/vmware/vic/issues/744)
And then there is the restart of the VCH Docker EndPoint VM alone (tracked in https://github.com/vmware/vic/issues/701).
For the latter I don't think there is much to "document" (the only behaviour should be that you restart the EndPoint VM and nothing happens all should work transparently).
For the former there may be a need to document the various option that using --restart
enables in the context of VIC.
@mreferre are you talking about docker --restart
here? Rather than an as-yet-unimplement vic-machine --restart
command?
@fdawg4l and @hmahmood, can you please confirm that you are talking about restarting the vApp, and not restarting the endpoint VM? I assume so, but want to be 100% sure. Thanks!
I was actually talking about the endpoint VM.
Thanks @fdawg4l and @hmahmood. Moving to To Do.
This is probably a candidate for the vSphere interop topic, for want of any other place to put it.
@npakrasi can you please take this on?
See also https://github.com/vmware/vic/issues/2079#issuecomment-261607770, which states that only the init.log file is persisted after a VCH reboot. This change is merged in PR https://github.com/vmware/vic/pull/3248.
Added to the interop.md file with input from Hasan:
vic-machine inspect
to obtain the new IP address.Covered by global doc review. Closing.
We should document that the list of things that will be implemented in https://github.com/vmware/vic/issues/701 are performed when you restart the VCH appliance.