At Tue, 15 Jul 2014 15:42:22 +0200, Valerio Pachera wrote: > > 2014-07-15 15:16 GMT+02:00 Hitoshi Mitake <mitake.hito...@gmail.com>: > > > > > 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.
Yes, your understanding is correct. When a new QEMU fails to acquire a lock of VDI, there are two possibilities: 1. other process (QEMU or tgt) is using it 2. previous process which used it died suddenly > > 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? I don't know the behavior of QEMU. I'll test it and report later. Thanks, Hitoshi -- sheepdog mailing list sheepdog@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/sheepdog
