OpenNebula

Hi,

Simon Boulet wrote:

I'm trying to understand how to use the new UNDEPLOYED VM state.

Simply put, it is the STOPPED state, but without a checkpoint file.

In my experiment, I noticed the TM MV action is being called (before VMM DEPLOY) when the VM is resubmitted from UNDEPLOYED state.

My VMs are deployed with persistent disks. Usually in the initial deployment, the TM LN action is called (not TM MV).

This is because the files are not taken from the image DS, but from the system DS. For a persistent disk, disk.0 may be just a link to the actual file in the image DS.

This is how a stop + resume operation works also.

Also I noticed some weird behaviour. If the initial resubmit fails (say my driver doesn't have the TM MV action implemented and fails), then OpenNebula will retry to redeploy the VM but this time it will call the TM LN action instead of TM MV.

I can confirm this, the second try calls LN instead of MV... we'll have to take a look at it.

Finally, if the second attempt (using TM MV) also fails, the VM is reverted to UNDEPLOYED state. Here I noticed a bug, the VM_HOOK seems to be called a second time but again using the UNDEPLOYED/ACTIVE previous states. Perhaps the VM should be turned into ERROR state and/or the VM_HOOK be called with PROLOG_UNDEPLOY/ACTIVE (or what ever previous state the VM was when the deployment failed).

We move the VM to undeploy to give it another change of being transfered/deployed in another host. If we set the VM to FAILED, you wouldn't be able to recover the current disks, since the only operations would be delete or delete --recreate.

Sorry if I'm vague or unclear, I really don't know what's going on, and have found very little documentation on the new UNDEPLOYED state. I'm trying to understand the various driver actions implicated in the UNDEPLOYED resubmit process.

Simon

Thanks!