Hi Dietmar,
I had increased the size in the past to 4096 since there had been
problems with canceled backups as discussed in the forum also, but they
never crashed the whole system.
# vzdump default settings
#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
size: 4096
maxfiles: 3
#script: FILENAME
#exclude-path: PATHLIST
And this setting works perfectly with 2.6.32-17, and also with
2.6.32-19 with manual backups from the webinterface, but not with a
scheduled one via cron with 2.6.32-19 on *this *node. On the two other
nodes there had been no problems same time with scheduled backups (with
much bigger VMs and CTs). The backup crashed even on a small,
non-channging (unused owncloud file server) CT with only 6GB HDD.
Please take a look on the lvdisplay output during a small, non system
destroying crash:
Allocated to snapshot 60,92%
So there should be enough space left?
I recognized the following difference between non-failing/failing:
After a crash the LV showed:
LV Size 4,00 GiB
Current LE 1024
Segments 1
Allocation inherit
During a non-failing backup it was
LV Size 2,55 TiB
Current LE 669651
COW-table size 4,00 GiB
COW-table LE 1024
Allocated to snapshot 60,92%
Snapshot chunk size 4,00 KiB
Segments 1
The 2,55 TiB in the working one correspond to the size of the data-LV:
LV Path /dev/promo3/data
LV Name data
LV Status available
# open 1
LV Size 2,55 TiB
Current LE 669651
Segments 1
Allocation inherit
I recognized during the crashingbackups, not to be able to do an 'ls
/mnt/pve/' - this ends with a hung and no output during the backup.
While a non-failing backup is running, there occurs no problem with
that. 'lvscan' shows same behaviour.
Funny seems also this difference between lvdisplay and lvscan during a
non-failing backup:
lvdisplay:
--- Logical volume ---
LV Path /dev/promo3/vzsnap-promo3-0
...
LV Status available
# open 1
LV Size *2,55 TiB*
Current LE 669651
...
lvscan:
...
ACTIVE Original '/dev/promo3/data' [2,55 TiB] inherit
ACTIVE Snapshot '/dev/promo3/vzsnap-promo3-0' [*4,00 GiB*] inherit
I could try again the new kernel with a higher size in vzcron.conf - but
it seems to me not to be the cause of a whole system crash. Even if the
size-parameter may be to small - in my opinion there should be no chance
for crashing the whole node with that?
many regards,
Martin
Dietmar Maurer <[email protected]> schrieb am 22.03.2013 06:36:
snapshot: Unable to allocate exception.
You run out of snapshot space! You should increase that (see 'man vzdump' -
parameter 'size').
_______________________________________________
pve-user mailing list
[email protected]
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
