Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Additional target states for virt module: "destroyed" and "paused" #5079
unpause looks fine here
This doesn't remove guests that are in shutdown state and probably should.
What should happen if the machine is not running? Should it start it and then pause? Or should it raise an error? This seems like it should probably be handled.
I'd suspect these commands are in the command form that they are probably because they don't lend themselves well to stateful management, but I'm open to exploring how to make that more logical.
"destroy" doesn't remove a guest (either from the stored libvirt XML definition, nor its disk image)
In libvirt terminology, "destroy" just means "immediate halt", like pulling the plug out, whereas "shutdown" means "send the (ACPI) shutdown signal, and leave it up to the VM when to shut itself down". IMO "destroy" was a bad choice of terminology, but it's what we have to live with.
AFAIK there are not separate states "VM was shutdown" and "VM was destroyed" (*). When you see state=shutdown it just means "not running", and there are two ways to get it into that state: command=shutdown or command=destroy. The first may not always work, e.g. if the VM is hung, and it could take a long time. The second may be what you wanted anyway, e.g. if this is a temporary VM that you want to halt immediately and don't care about filesystem corruption.
In ansible, being able to request state=destroyed would be much more convenient than command=destroy, because command=destroy fails if the VM is not currently running (even though that is the state you wanted!)
I thought along the same lines as you, but I took the view that if the machine is currently shutdown, it should stay like that. There is no "state=unpaused", so when you want to unpause a machine you set "state=running". If the machine were shutdown that would of course start it.
There seems to be little point in having a "start-then-immediately-pause" operation, and in any case that would be difficult to implement safely.
(*) I note that there are two libvirt states which are mapped to "shutdown" in ansible:
After sending a 'destroy' command, or even after manually killing the KVM process, ansible says the domain is 'shutdown'. So I don't know what condition can result in 'crashed'
Looking at libvirt source (libvirt/include/libvirt/libvirt.h) I see:
So actually 4 and 5 are different: 4 means "in the process of shutting down" and 5 is "off".
It would be better IMO if ansible reported "shutting_down" and "shutdown" as two separate states. Then the idempotent "shutdown" operation would not send a second signal to a machine which has already been told to shut down.
Yes, sorry about my fuzzy use of language, but I was trying to distinguish the "state=foo" option of the virt module from the "command=foo" option.
Maybe there is value in having both state=paused and state=unpaused.
state=paused: "if this maching is running, pause it. But if it's paused or shutdown, leave it alone."
state=unpaused: "if this machine is paused, unpause it. But if it's running or shutdown, leave it alone."
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
On 01/12/2013 22:29, Michael DeHaan wrote:
Once you have completed this work, you want to put them back as they
However this isn't a use case that I need, so I don't really mind if we