Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
First, thanks for the patch! Further comments inline: Signed-off-by: Wolfgang Link wolfg...@linksystems.org --- PVE/QMPClient.pm | 64 +++--- --- PVE/QemuServer.pm | 32 +++ qm| 31

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
Just reading: http://wiki.qemu.org/Features/QAPI/GuestAgent I wonder what happened to the qga_proxy feature? Is that still not implemented? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
I wonder what happened to the qga_proxy feature? Is that still not implemented? No, It's never has been implemented. Sigh! So we always run into timeouts if guest-agent is not running, and there is no way to avoid that? ___ pve-devel mailing list

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Alexandre DERUMIER
Sigh! So we always run into timeouts if guest-agent is not running, and there is no way to avoid that? I think that libvirt sent always guest-sync before doing the real command, to see the if guest-agent is alive. So, I think we can sent guest-sync with a real small timeout, like 1s, before

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
I think that libvirt sent always guest-sync before doing the real command, to see the if guest-agent is alive. So, I think we can sent guest-sync with a real small timeout, like 1s, before doing a longer qga command which need a bigger timeout. Ah, OK. Or we can save the state of the

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Alexandre DERUMIER
Ah, OK. Or we can save the state of the last command into a temp file, so that we can avoid the delay? I'm not sure, because It's possible that qga daemon can be stopped, or crash, - Mail original - De: Dietmar Maurer diet...@proxmox.com À: Alexandre DERUMIER

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
Ah, OK. Or we can save the state of the last command into a temp file, so that we can avoid the delay? I'm not sure, because It's possible that qga daemon can be stopped, or crash, Right, that does not really help. Instead, the guest-agent should send some kind of 'alive' signal

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Michael Rasmussen
On Mon, 24 Nov 2014 17:52:29 + Dietmar Maurer diet...@proxmox.com wrote: Right, that does not really help. Instead, the guest-agent should send some kind of 'alive' signal every second, which we could track inside qemu? Could some listening on qmp event be used? -- Hilsen/Regards

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
Right, that does not really help. Instead, the guest-agent should send some kind of 'alive' signal every second, which we could track inside qemu? Could some listening on qmp event be used? You need to have an open connection to do that. I guess the best way to solve that problem is to

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Alexandre DERUMIER
Right, that does not really help. Instead, the guest-agent should send some kind of 'alive' signal every second, which we could track inside qemu? What do we want to do you qga ? if it's only to send some commands like filesystem freeze|unfreeze, stop[start , I think that calling guest-sync

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
What do we want to do you qga ? 1.) send guest command like shutdown, freeze, unfreeze 2.) query guest status if it's only to send some commands like filesystem freeze|unfreeze, stop[start , I think that calling guest-sync before it's not a big overhead. The problem is the timeout if

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Alexandre DERUMIER
The problem is the timeout if guest agent is not running (not the overhead). But maybe it is not a big problem, and not worth the efforts? 1.) send guest command like shutdown, freeze, unfreeze I think it's not a problem here. a small extra 1s timeout on guest-sync is ok I Think. (and if

[pve-devel] vm_deviceunplug question

2014-11-24 Thread Dietmar Maurer
For example, for virtio we call qemu_devicedelverify(): if ($deviceid =~ m/^(virtio)(\d+)$/) { qemu_devicedel($vmid, $deviceid); return undef if !qemu_devicedelverify($vmid, $deviceid); return undef if !qemu_drivedel($vmid, $deviceid); But for lsi/scsi we simply do: if

Re: [pve-devel] [PATCH 2/2] now if the QMP command starts with guest-+ , it will bind dynamicly to the VMID.qga socket. To test the function vmtime is implemented which return the vm UNIX Time.

2014-11-24 Thread Dietmar Maurer
2.) query guest status timeout could be a problem in pvestatd (not sure where you want to query guest status) Yes, I thought about doing this in pvestatd. Maybe pvestatd can save if last qga command was successful (guest agent online). If not, it just sends 'guest-sync' with short

Re: [pve-devel] [PATCH v4 14/14] implement API/CLI to get pending changes

2014-11-24 Thread Dietmar Maurer
I don't known why, but I can't fill the datastore with a simple model like Ext.define('pendingconf', { extend: Ext.data.Model, fields: [ 'key', 'value', 'pending', 'delete' ], idProperty: 'key' }); Do you get some kind of error message?

Re: [pve-devel] [PATCH v4 14/14] implement API/CLI to get pending changes

2014-11-24 Thread Alexandre DERUMIER
Do you get some kind of error message? no, no error. But I think my problem is that I used the jsonobject reader, which only work with key-value I dig a little bit today. (Damn, I don't like js ;) - Mail original - De: Dietmar Maurer diet...@proxmox.com À: Alexandre DERUMIER