VM becomes unresponsive to bosh after reboot about bosh-windows-stemcell-builder HOT 6 CLOSED

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/161338351

The labels on this github issue will be updated when the story is started.

from bosh-windows-stemcell-builder.

Hey @gossion

Bosh does not currently support a workflow where VM restarts are managed outside of the Bosh director. In case you do need to restart VMs, the bosh cli has commands to do the same. Restarting the VM from the portal leads to the BOSH director thinking the VMs have been torn down and it tries to recreate them.

Was there a particular use case that you had which required the VMs to be restarted from the Azure portal? It would help us understand the requirement a little better.

Thanks!!

from bosh-windows-stemcell-builder.

Thanks @ashwin-venkatesh . Currently, I don't have any workload blocked, I just saw the error and thought that it could be an issue.

A use case that I can think is a test environment, people would like to stop the VMs for purpose of cost saving, and later on when they need to use the test environment again they start the VMs, and finally they find that the VMs are not recovered.

from bosh-windows-stemcell-builder.

Hey @gossion

That is a reasonable use case. Bosh does currently support this workflow using the bosh stop command. It also includes the --hard flag which deletes the VMs but holds onto the persistent disks.

Those would be the recommended way to achieve the desired result. This should ensure things work seamlessly.Bosh maintains it's own state of the world and does not work as intended when changes are made to a VM state via mechanisms external to it.

I hope this addresses the above concern. Do you have other questions or would it be alright if I closed this issue?

from bosh-windows-stemcell-builder.

Additionally, you can use bosh start to restart a stopped deployment.

from bosh-windows-stemcell-builder.

Thanks @ashwin-venkatesh .

There is no API for CPI to stop (which is allocate on Azure) a VM, for purpose of cost saving I need to delete the VM (bosh stop --hard) which is not convenient to find the instance id once it is deleted (it is not shown on bosh vms anymore). So I think it is better if the VM can come back to service after an expected/unexpected reboot.

Anyway, I am not blocked. I will close this issue, but think it is a nice-to-have feature.

from bosh-windows-stemcell-builder.