> if think we shouldn't try to send after that the other command with 1 hour > timeout...
>>Sure, once we run into a timeout we should not send the second command. I have looked at libvirt/ovirt. It seem that's it's possible to detect if agent is connected, through a qmp event VSERPORT_CHANGE. https://git.qemu.org/?p=qemu.git;a=commit;h=e2ae6159 https://git.qemu.org/?p=qemu.git;a=blobdiff;f=docs/qmp/qmp-events.txt;h=d759d197486a3edf3b629fb11e9922ad92fb041a;hp=9d7439e3073ac63b639ce282c7466933ccb411b4;hb=032baddea36330384b3654fcbfafa74cc815471c;hpb=db52658b38fea4e54c23c9cfbced9478d368aa84 previously, they send a guest-ping with a short timeout before each command, and since this commit https://www.redhat.com/archives/libvir-list/2014-November/msg00708.html they catch the VSERPORT_CHANGE to known if the daemon is connected or not to the serial device. We don't catch events currently, but maybe could we patch qemu to store the status somewhere instead event only, and retrieve it with a qmp command before calling qga ? ----- Mail original ----- De: "dietmar" <diet...@proxmox.com> À: "aderumier" <aderum...@odiso.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com> Envoyé: Dimanche 20 Mai 2018 15:51:37 Objet: Re: [pve-devel] pvedaemon hanging because of qga retry > if the guest is so loaded, than it can't even send reponse to guest-ping > (with > a "short" timeout of some seconds, not ms!), AFAIK this is quite common ... (unfortunately). We had several support cases in the past (several seconds delay), but I do not remember how to reproduce. I will ask the support team next week ... > if think we shouldn't try to send after that the other command with 1 hour > timeout... Sure, once we run into a timeout we should not send the second command. _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
