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 .