Search results

Ok, I think we can rule out lockups caused by no disk space :-) There is a lot of different stories about these lockups on the internet. There is a problem with KVM on KVM sometimes, in other cases it has to do with physical hardware problems. Or it can be buggy network drivers causing trouble...

This graphics chip needs the i965 kernel module. Try installing package i965-va-driver See for references: https://wiki.archlinux.org/index.php/intel_graphics https://wiki.gentoo.org/wiki/Intel

Can you show the usage for the rpool2? Something like zfs list -r rpool2

Are you running emulators within the machine by any chance? What is the output of uname -a in the KVM? Also check if you have sufficient disk space left in the disk image (qcow?).

You could parse it from: cat /proc/1/cgroup

Seems like you have a problem of the container not correctly shutting down. You could loop mount it and run fsck on it. You can make a copy of the file first for backup if you don't have a current backup. losetup -f --show /var/lib/vz/images/106/vm-106-disk-1.raw fsck /dev/loopx (x=number as...

That is true, it is only used with the backup scripts in vzdump. Maybe replace the tar executable with a wrapper? #!/bin/bash exec ionice -c 7 /usr/bin/tar.real "$@" You have to look into dpkg-divert then also.

What does this say? file -s /var/lib/vz/images/106/vm-106-disk-1.raw

This is a different issue. Please start a new thread for it.

You have to test from inside the container. Through the web console or on the host with pct. pct enter 1013

I don't see a noacl in the mount options, so it should already be enabled. You can also test directly: apt-get install acl mkdir /var/testacl setfacl -m d:g::rwx /var/testacl rm -r /var/testacl If the setfacl doesn't report "Operation not supported" then acl's are enabled.

It is contingent upon a realloc failing. You have to catch the process at a moment it is just somehow not able to quickly allocate a new memory page that is large enough. This probably happens mostly with containers that have very large tasklists and a lot of systemd activity with cgroups...

Then you will have to look at the process list from the host console, because any process entering the containers cgroup would "freeze" immediately. I looked at the source code of lxc and the lxc-freeze program just loops and checks once per second if the entire group has become FROZEN. If you...

Nominally the freeze should be near instantaneous but in your cases it seems to stretch out indefinitely. The lxc-freeze command does not return until the state becomes FROZEN instead of FREEZING. Are there processes in uninterruptible state before the freeze in the container? Any stat columns...

Are the program dtach and vncterm present? Did you change domainnames or hostnames, do you have certificates in /etc/pve?

Do the containers you backup use connections to the same NFS server? Can you reproduce the problem by just using vzdump repeatedly on one container? vzdump containerid -mode suspend It just seems as if the backup itself freezes also. You can check the state of a container with lxc-info -n...

The best thing to do is to create a new mountpoint for it in the zfs pool and set that to acl. Otherwise you may run into a host of trouble with new LXC containers. zfs create -o mountpoint=/mnt/vztmp rpool/vztmp zfs set acltype=posixacl rpool/vztmp Now set /mnt/vztmp in your...

on NFS, the containers themselves or the backup?

Maybe some details to allow for reproduction. What storage is used for the LXC containers? Are they all running or are there also some containers that are already stopped before the backups?

Ah, yes if the USB drive is mounted, then its mount hides the underlying filesystem. Usually you mount a drive on an empty mount directory, but if it is filled with files, they will "just" disappear from view, until you umount the overmounted device. Maybe set your backup to a subdirectory on...