2014-07-15 15:16 GMT+02:00 Hitoshi Mitake <[email protected]>:
> > As Valerio points, this problem is not only related to the VDI locking > feature. For avoiding this problem, we need to run "dog vdi check" > after sudden death of QEMU process or node. > Ok, that's good to know. So a sudden death of qemu will just leave the lock that may be removed by vdi check or a new command if required. So, generally speaking: if I try to run a guest and qemu exits with an error complaining about the lock, it means another process is currently using it; if I don't find this process, it means a qemu process has die previously and I need to run vdi check. That sounds more safe than before because I may have run the guest without knowing the vdi may be in an inconsistent state because of a crash I didn't know of. The down side of is that the bigger the vdi, the longer the time for the check, but that is unrelated to the vdi locking patch. One more question: kill -15 vs kill -9: Is kill -15 going to terminate qemu in a "sweet" way, so it flushed it's data and remove the lock before dieing? Or does it have the same effect (from the lock point of view) of a kill -15?
-- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
