Re: [pve-devel] BUG? Backup hangs

2015-02-23 Thread Eneko Lacunza
Hi Detlef, Have you checked syslog and dmesg for other errors? Is NFS on another machine? What S.O. does run VM 997? What network and disks? On 22/02/15 16:05, Detlef Bracker wrote: Dear, I dont know why, but 2nd time the scheduled backup hangs without information - why - runs now for

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Alexandre DERUMIER
I have also notice another bug, after browsing some vms config, I see a lot of api call to /current /pending, for differents vms, even if I'm not on this vm I can reproduce this, with fast click on different vms on the tree. This produce a lot of call to /pending /api for lot of vms, and

[pve-devel] [PATCH] rrd : init with timeframe from state manager

2015-02-23 Thread Alexandre Derumier
avoid to init the rrd with default timeframe, then reload with timefrom state manager this avoid to reload twice the rrds Signed-off-by: Alexandre Derumier aderum...@odiso.com --- www/manager/panel/RRDView.js |7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Dietmar Maurer
I can reproduce this, with fast click on different vms on the tree. This produce a lot of call to /pending /api for lot of vms, and then I slowdown the browser for others api calls. Seem to be a race with me.on('show', me.rstore.startUpdate); me.on('hide', me.rstore.stopUpdate);

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Dietmar Maurer
see, but generally there will be a loading indicator until all the elements required to display accurate detail have come back from the server, so that other users, with less technical exposure to web dev, understand that the data they're looking at may not be accurate. Implementing something

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Dietmar Maurer
It's take around 0,3s to be hidden, same than for refresh the default hardware config to pending hardware config. This is just the time to load the values. So it is normal/correct to display default values until we get the result from the server? ___

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Daniel Hunsaker
That's what I intended to say there, yes. On Mon, Feb 23, 2015, 01:44 Dietmar Maurer diet...@proxmox.com wrote: see, but generally there will be a loading indicator until all the elements required to display accurate detail have come back from the server, so that other users, with less

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Alexandre DERUMIER
This is just the time to load the values. So it is normal/correct to display default values until we get the result from the server? I think it better to display nothing in grid, than defaults values. Isn't it possible to wait that the api call is done before displaying grid ? (beforerender

Re: [pve-devel] proxmox 3.4, some visual glitch refresh on qemu hardware vew

2015-02-23 Thread Alexandre DERUMIER
I have check with firebug, I'm also seeing rrds loaded twice when I choose a vm. This case is if we choose a timeframe != than hour average, Then it's always loading hour average first (default value), then refresh with select timeframe. this add me around 100ms extra wait time. - Mail

Re: [pve-devel] [PATCH] rrd : init with timeframe from state manager

2015-02-23 Thread Dietmar Maurer
On 02/23/2015 01:17 PM, Alexandre Derumier wrote: avoid to init the rrd with default timeframe, then reload with timefrom state manager this avoid to reload twice the rrds Applied, thanks! ___ pve-devel mailing list pve-devel@pve.proxmox.com

Re: [pve-devel] [PATCH] support QinQ / vlan stacking

2015-02-23 Thread Andrew Thrift
We have found you need to nest the bridges to get QinQ to work in all scenarios. e.g. The above patch will work for MOST scenarios, but if you attach a vlan aware VM to the parent vmbr0 bridge it will cause traffic to the VM's to stop, or will not be able to see the tagged frames. The patch we