cmd");
I'll send a patch
- Mail original -
De: "aderumier" <aderum...@odiso.com>
À: "Thomas Lamprecht" <t.lampre...@proxmox.com>
Cc: "pve-devel" <pve-devel@pve.proxmox.com>
Envoyé: Mardi 22 Mai 2018 09:59:37
Objet: Re: [pve-devel] pvedaem
correctly?
yes !
- Mail original -
De: "Thomas Lamprecht" <t.lampre...@proxmox.com>
À: "pve-devel" <pve-devel@pve.proxmox.com>, "aderumier" <aderum...@odiso.com>,
"dietmar" <diet...@proxmox.com>
Envoyé: Mardi 22 Mai 2018 09:56:
et...@proxmox.com>
> À: "aderumier" <aderum...@odiso.com>
> Cc: "pve-devel" <pve-devel@pve.proxmox.com>
> Envoyé: Lundi 21 Mai 2018 09:56:03
> Objet: Re: [pve-devel] pvedaemon hanging because of qga retry
>
>> I have looked at libvirt/ovirt.
> On May 17, 2018 at 11:16 PM Alexandre DERUMIER wrote:
>
>
> Hi,
> I had a strange behaviour today,
>
> with a vm running + qga enabled, but qga service down in the vm
>
> after theses attempts,
>
> May 17 21:54:01 kvm14 pvedaemon[20088]: VM 745 qmp command failed -
> On May 21, 2018 at 3:02 PM Alexandre DERUMIER wrote:
>
>
> >>Seems this patch does not solve the 'high load' problem at all?
>
> I can't reproduce this high load, so I can't say.
Its holiday today in Austria. But I will ask our support team tomorrow how to
reproduce
longer timeout.
- Mail original -
De: "dietmar" <diet...@proxmox.com>
À: "aderumier" <aderum...@odiso.com>
Cc: "pve-devel" <pve-devel@pve.proxmox.com>
Envoyé: Lundi 21 Mai 2018 09:56:03
Objet: Re: [pve-devel] pvedaemon hanging because of qga
> 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
>
uot;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
> 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
mand.
what do you think about this?
- Mail original -
De: "dietmar" <diet...@proxmox.com>
À: "aderumier" <aderum...@odiso.com>
Cc: "pve-devel" <pve-devel@pve.proxmox.com>
Envoyé: Vendredi 18 Mai 2018 19:03:19
Objet: Re: [pve-devel] pvedaemon
> >>If you simply skip commands like 'guest-fsfreeze-thaw'
> >>your VM will get totally unusable (frozen). So I am not
> >>sure what you want to suggest?
>
> I'm not sure, but don't we have 2 timeout here ?
>
> 1 for connect , and 1 for command execution ?
what for?
> I would like to be
l original -
> De: "aderumier" <aderum...@odiso.com>
> À: "pve-devel" <pve-devel@pve.proxmox.com>
> Envoyé: Vendredi 18 Mai 2018 00:37:30
> Objet: Re: [pve-devel] pvedaemon hanging because of qga retry
>
> in qmpclient : open_connection
>
> we use $elapsed >= $timeout.
>
> Isn't this timeout for command execution time and not connect time ?
>
> I'm seeing at the end:
> $self->{mux}->set_timeout($fh, $timeout);
>
> seem to be the command execution time in the muxer
>
I guess both should be shorter than $timeout?
pve-devel" <pve-devel@pve.proxmox.com>
Envoyé: Vendredi 18 Mai 2018 00:37:30
Objet: Re: [pve-devel] pvedaemon hanging because of qga retry
in qmpclient : open_connection
for (;;) {
$count++;
$fh = IO::Socket::UNIX->new(Peer => $sname, Blocking => 0, Timeout => 1);
last if $fh;
if
in qmpclient : open_connection
for (;;) {
$count++;
$fh = IO::Socket::UNIX->new(Peer => $sname, Blocking => 0, Timeout =>
1);
last if $fh;
if ($! != EINTR && $! != EAGAIN) {
die "unable to connect to VM $vmid $sotype socket - $!\n";
}
15 matches
Mail list logo