[pve-devel] [PATCH http-server 2/2] Replace own Websocket parser with Protocol::Websocket.

It needs "libprotocol-websocket-perl" installed, currently not available via Debian repos. I got a Debian package for that. This partially fixes NoVNC over nginx and implements more Websocket protocols. I tested: NoVNC with UTF-8 xterm.js with UTF-8 pventer Run cacafire in all 3 a long

[pve-devel] [PATCH http-server 0/2] Replace own Websocket parser with Protocol::Websocket.

It needs "libprotocol-websocket-perl" installed, currently not available via Debian repos. I got a Debian package for that. https://git.lxch.eu/pcdummy/libprotocol-websocket-perl/-/jobs/75/artifacts/browse This partially fixes NoVNC over nginx and implements more Websocket protocols. I tested:

[pve-devel] [PATCH http-server 1/2] Add .gitignore

Signed-off-by: René Jochum --- .gitignore | 4 1 file changed, 4 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..cf75b1b --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +build/ +*.deb +*.buildinfo

Re: [pve-devel] pvedaemon hanging because of qga retry

> 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

Re: [pve-devel] pvedaemon hanging because of qga retry

>>Seems this patch does not solve the 'high load' problem at all? I can't reproduce this high load, so I can't say. My main concern is to not wait for a down daemon. (which will never response). If we can be sure that daemon is running, with high load, simply wait for a response with a longer

Re: [pve-devel] pvedaemon hanging because of qga retry

> 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 >

Re: [pve-devel] pvedaemon hanging because of qga retry

> 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.