Re: [libvirt] [PATCH 1/2] Timeout QEMU monitor replies after 30 seconds

On Wed, Jun 22, 2011 at 16:47:18 +0100, Daniel P. Berrange wrote: > If the QEMU process has been stopped (kill -STOP/gdb), or the > QEMU process has live-locked itself, then we will never get a > reply from the monitor. We should not wait forever in this > case, but instead timeout after a reasonable amount of time. > > NB if the host has high CPU load, or a single monitor command > intentionally takes a long time, then this will cause bogus > failures. In the case of high CPU load, arguably the guest > should have been migrated elsewhere, since you can't effectively > manage guests on a host if QEMU is taking > 30 seconds to reply > to simply commands. Since we use background migration, there > should not be any commands which take significant time to > execute any more The thing I'm most concerned about is that is far too easy to get into such situations especially since disk cache subsystem in Linux kernel is not the best thing in the world. While I agree that running guests on a loaded host is not very clever and guests should rather be migrated elsewhere, such situation doesn't have to be intentional. In other words, in case of a malfunction of some kind (some processes go crazy, network disruptions, ...) QEMU may require more than a timeout seconds to respond and we will penalize an innocent QEMU process because we won't be able to control it anymore even though the issues get fixed.