Search results

try setting /etc/vzdump.conf size: 4000 ------------------------- I think that the max size is the Vfree shown in the output of 'vgs' . here is one node here: root@fbc1 /etc # vgs VG #PV #LV #SN Attr VSize VFree fbc1 1 1 0 wz--n- 831.30g 31.30g pve 1 3 0 wz--n-...

on this node suspend backup works, i check earlier logs and we were using suspend until yesterday. here is the win7 backup in suspend mode: Detailed backup logs: vzdump 10159 --quiet 1 --mailto fbcadmin@fantinibakery.com --mode suspend --node fbc1 --compress 1 --maxfiles 1 --storage...

OK i just did 2 tests, a suspend and a stop mode backup, see the results: vzdump 17014 --quiet 1 --mailto xxxxx --mode suspend --node fbc1 --compress 1 --maxfiles 1 --storage fbc1-storage 17014: Dec 15 06:30:02 INFO: Starting Backup of VM 17014 (qemu) 17014: Dec 15 06:30:02 INFO: status =...

I'll check the bug but will not get into the windows issues. I'd rather clean out a pig farm .

these are kvm's which have been getting successfully backed up for weeks. they are win7 and a special ltsp terminal tester [ it has no hdd, boots from network ] . A clone [restored from the same prox 1.9 win7 backup ] of the win7 kvm is on another node, and I just shut it down successfully...

No, It fails with a timeout.

I'll set the failed backup to run again tomorrow 7am Boston time tomorrow, as I'll be on site in case there is a freeze.

log for cli ok : Detailed backup logs: vzdump 10159 --mailto fbcadmin@fantinibakery.com --mode stop --compress 1 --maxfiles 1 --storage fbc1-storage --node fbc1 10159: Dec 14 19:50:06 INFO: Starting Backup of VM 10159 (qemu) 10159: Dec 14 19:50:06 INFO: status = stopped 10159: Dec 14...

I was able to ge tthe backups to work from command line by doing this: 1- qm stop 10159 2-then copied and paste the line from /etc/cron.d/vzdump [ except the quiet part ] vzdump 10159 --mode stop --mailto xxxx --node fbc1 --compress 1 --maxfiles 1 --storage fbc1-storage 3 ps -ef|grep...

2 backups in a row failed on a node which did not have a failed backup since beta1 Detailed backup logs: vzdump 10159 --quiet 1 --mailto fbcadmin@fantinibakery.com --mode stop --node fbc1 --compress 1 --maxfiles 1 --storage fbc1-storage 10159: Dec 14 19:00:02 INFO: Starting Backup of VM...

getting pfsense working on proxmox seemed like a complex difficult thing to do before doing so . just setup the network devices and you'll be ok . otherwise ask. try follow threads Udo made suggestions in. those helped here. then when done maybe you could put a how to do it on the wiki...

#try this to start: aptitude update #then if no error aptitude full-upgrade # if error copy and paste the result

you need a fixed i/p address . As Udo said, edit /etc/interfaces or if that seems hard, re install which is easy anyways.

try to change your backup type to suspend, as I do not think it uses lvm snapshot. otherwise use a stop type backup.

Re: backup causes this sys logs do not help, here is today's vzctl.log: 2011-12-12T21:01:21-0500 vzctl : CT 8002 : Configure veth devices: veth8002.0 2011-12-12T21:01:22-0500 vzctl : CT 8002 : Container start in progress... 2011-12-13T07:09:29-0500 vzctl : CT 8002 : Stopping container ...

Re: backup causes this none of the other ct's is accessable. can not use vzctl or ssh to enter. those other ct's had not had a backup done. the system got stuck during the 1-st backup.

Re: backup causes this pve backup log: INFO: starting new backup job: vzdump --quiet 1 --mailto xxxx --mode snapshot --node fbc186 --all 1 --compress 1 --maxfiles 1 --storage fbc186storage INFO: Starting Backup of VM 10001 (openvz) INFO: CTID 10001 exist mounted running INFO: status = running...

Re: backup causes this root@fbc186 /etc # pveversion -v pve-manager: 2.0-14 (pve-manager/2.0/6a150142) running kernel: 2.6.32-6-pve proxmox-ve-2.6.32: 2.0-54 pve-kernel-2.6.32-6-pve: 2.6.32-54 lvm2: 2.02.86-1pve2 clvm: 2.02.86-1pve2 corosync-pve: 1.4.1-1 openais-pve: 1.1.4-1 libqb: 0.6.0-1...

backup causes this This has been randomly occurring to us. When we use snapshot backup the containers can not be entered into or stop. this has happened since the 1-st beta on one system, and I thought it was due to hardware issues as it had older disks. but after todays backup it happened...

I am able to connect to a kvm running ubuntu lts from offsite using tigervnc . However control keys do not work. for instance using nano ctl + x just puts an x on the screen . Does anyone have a suggestion to solve the issue? using pve console, ctl + x in nano works as expected.