Search results

When dealing with migration of large OpenVZ containers (500-700GB) we noticed the vzquota takes very long time before the migrated container can start on the second node. We tested using VZQUOTA=NO on a per-container configuration, it seems to work but no disk usage info are present on proxmox...

We are trying to understand best way to duplicate VZ container over a spare server. The idea behind this need is the capability to quickly re-boot VZ containers on the spare server in case of a complete loss of the main server. The condition where the VZ containers on the spare server are some...

Dietmar, you have right, that's the reason I do not understand why a container can use ntpd, and sync Kernel, without capability. The only difference was the network type. :-)

Thanks Dietnar, yes, the capability can be set, however the question was more keen to understand why a container sync time without such capability and if there are differences running NTPD in a bridged container.

After browsing the forums and googling around, I'm still not sure about the correct approach for a NTP server inside a container. The need is for a ntpd daemon running in a OpenVZ container with bridged ethernet (vmbr0) and acting as time server for a local network. Just installing and running...

Ok, searched for the corresponding lines in OpenVZ.pm but I was unable to find them. I'm not sure I correctly understood where to do the changes. I did them in QemuServer.pm but none of the messages added was logged when issuing: # vzdump --dumpdir=/media/extstorage/vzdumptest --maxfiles 1...

Thanks Dietmar, added the lines to QemuServer.pm, but no messages appears. Are we sure we should add them to this file ? We are doing dumps of OpenVZ containers. Maybe OpenVZ.pm is involved ?

I launched manually a vzdump: # vzdump --dumpdir=/media/extstorage/vzdumptest --maxfiles 1 --snapshot --ionice 0 101 Looking at the folder where vzdump is done, I noticed the folder ".tmp" that appears to stay there even after the messages of tar completed: .... .... INFO: creating archive...

# pveperf CPU BOGOMIPS: 10400.28 REGEX/SECOND: 449780 HD SIZE: 94.49 GB (/dev/mapper/pve-root) BUFFERED READS: 154.28 MB/sec AVERAGE SEEK TIME: 11.68 ms FSYNCS/SECOND: 1231.74 DNS EXT: 61.63 ms DNS INT: 1.12 ms Last night we tested a vzdump using...

Tested, with: # vzdump --dumpdir=/media/extstorage/vzdumptest --maxfiles 1 --snapshot --ionice 2 --bwlimit 20480 101 Not much difference: Oct 12 15:17:17 INFO: Starting Backup of VM 101 (openvz) Oct 12 15:17:17 INFO: CTID 101 exist mounted running Oct 12 15:17:17 INFO: status = CTID 101 exist...

Thanks for the hint. The test made: 1. dump using the external sotrage as dump dir (on a different folder): # vzdump --dumpdir=/media/extstorage/vzdumptest --maxfiles 1 --snapshot --bwlimit 20480 101 Oct 12 11:09:43 INFO: Starting Backup of VM 101 (openvz) Oct 12 11:09:43 INFO: CTID 101 exist...

Dietmar: # pveperf /media/extstorage/vzdump CPU BOGOMIPS: 10400.28 REGEX/SECOND: 459861 HD SIZE: 2750.67 GB (/dev/mapper/backups) BUFFERED READS: 30.02 MB/sec AVERAGE SEEK TIME: 18.03 ms FSYNCS/SECOND: 122.33 Tried also to delete a old single vzdump .tar file...

From some days we noticed the umount and lvremove steps takes very long to perform, with no apprent reason. From a time point of view the vzdump of the same group of OpenVZ containers (sized approximately 1GB each) completed in about 30 minutes now takes about 30-40 minutes for each container...

Yes, vzdump failed whith 100% snapshot full. Increased size to 16GB, let see. Thanks, Andrea

Thanks, we already have /mnt in PRUNEPATHS, that solved the problem of unmountable snapshot, not the Input/Output issue.

Sorry, first container is 1GB, not 1TB... LV has 300GB space available. # pveperf CPU BOGOMIPS: 9199.52 REGEX/SECOND: 425544 HD SIZE: 18.21 GB (/dev/mapper/pve-root) BUFFERED READS: 63.74 MB/sec AVERAGE SEEK TIME: 10.14 ms FSYNCS/SECOND: 705.90 DNS EXT...

We are experiencing the very same problem, thus we created a /etc/vzdump.conf containing the following line: size: 2048 (first try) then size: 4096 (second try) In both cases vzdump yileds errors such as: INFO: tar: ./etc/hostname: Warning: Cannot stat: No such file or directory The node...

You are right, firmware non free does not contain the missing driver. Wondering if the controller will continue to work without problem using the driver inlcuded in the previous kernel: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561309

Re: Proxmox 1.5, 3ware, partitions size...mixed - SOLVED For those who may be interested, PVE 1.6 works fine with 3ware 9650SE-4LPML Andrea

Hi, updated today to the latest PVE 1.6 kernel, the warning is still present. I tested on a system with the following Ethernet hardware (from lspci): Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Tried rebooting and...