Re: [libvirt] util: client: shall libvirtd record task histories?
On Wed, Apr 08, 2015 at 15:40:36 +0800, zhang bo wrote:
We recently encountered a problem:
1) migrate a domain
2) the client unexpectedly got *crashed* (let's take it as virsh command)
3) *libvirtd still kept migrating the domain*
4) after it's restarted, the client didn't know the guest is still migrating.
The problem is that libvirtd and the client has different view of the task state. After
migration,
the client may wrongly think that something's wrong that the domain got unexpectedly
migrated.
In my opinion, libvirtd should just *execute* tasks, like the hands of a human,
while clients should be the brain to *schedule and remember* tasks.
So, In order to avoid this problem,we should let the client record all the taskes
somewhere,
and reload the states after its restart. the client may cancel or continue the task as it
wishes.
Libvirtd should not record the task status.
Not really. It's libvirtd, the daemon, which has to remember everything.
It manages the state of all domains running on a host and synchronizes
all clients that want to change state of the domains. Remember, even if
a client is not restarted, domains my unexpectedly migrate somewhere
else because another client might have asked for it.
That said, if you're implementing a higher management layer which
manages domains using libvirt and you know it is going to be the only
client talking directly to libvirt, you can remember the state there if
you want. However, it's not something libvirt itself should or could do.
But you will most likely need to synchronize the state with libvirtd in
case the client is restarted. Even libvirtd has to synchronize its
internal state with all running QEMU processes when it is restarted
because the state might have changed.
Jirka