OpenNebula

Hi,

I think OpenNebula already supports this. If you issue a onevm shutdown command the VM will be gracefully shutdown. Additionally if you want to preserve the state you can label the VM disks with save=yes. Later the user can use that disk to restart the VM. OpenNebula does not overwrite the original disk, but if you want you can easily achieve this with a hook (simply mv's $ONE_LOCATION/var/$VMID/disk.0 to the original file...)

Hi,
thanx for your feedback!

According to our previous tests, we couldn't restart a shutdown VM, just delete it.
So I thought the built in shutdown command meant end of life. Since I might mess up
something I'll rerun the tests to see what is happening:)

Cheers,
Gyula

Well, yes you have to "resubmit", i.e. onevm create, but it will use the modified VM images. So onevm create == restart. Right now, we do not have a template DB...

Ok, I see the point, thank you:)

There's a problem related to dynamic IP assignment. In our context we have to support virtual clusters, but the issue is more general, it can come up in any context when there's more then one VM within a virtual network (which is very likely:)).

Example: Assume that the VM had a public IP assigned to it dynamically (eg. from a range network), and the user stoped, then later restarted it with the above "resubmit" approach. Then it might happen that an intermediate VM request already allocated its previous IP address, thus the system can do nothing but assign a new public IP.

Please consider my request in your future plans:)

Cheers,
Gyula

Hi,

Then why not taking out the IP you want to keep for that VM from the VNet? However, there are some benefits of keeping the VM defined in DB. When a VM is shutdown it will end in a DONE state, this is we dispose the template and free the associated resources (like IP's). It would be more or less straight forward to move the VM to the HOLD state if it is marked to be kept.

Summary:

1. Standard life cycle, the current one (simplified)

(create)---> PENDING ---(deploy)---> RUNNING ---(shutdown)--->DONE 

2.- Keep VM template

(define) ---> HOLD ---(release) ---> PENDING ---(deploy)---> RUNNING ---(shutdown)
               ^                                                             |
               |---------------- (will not free network leases) --------------

Note that the resources used by the VM in the physical workernode are freed and when you release the VM it can end up in other physical workernode...

Does it make sense?

Cheers

Hi,

taking out the IP from the VNet is new thing for me:) To my understanding this could be done by resubmiting the VNet (delete -> take out the IP -> recreate the VNet). Does this work when there are active leases? As far as I see it shouldn't... since it would mess up the lease logic... But again I could be wrong.

I put my vote on the create/define scenarios:)

Cheers,
Gyula