Search results

Tank you for the hint. In my case I have removed domain-name-servers, domain-search and, host-name : #request subnet-mask, broadcast-address, time-offset, routers, # domain-name, domain-name-servers, domain-search, host-name, # dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn...

Again, I had the same concerns after backup crash. Removed whole entry in .conf file but snapshot remain in zfs. Is it safe to remove it with zfs destroy rpool/data/subvol-111-disk-1@vzdump ?

Hi, Take a look at Cannot remove Snapshot ( VM is locked (snapshot-delete) )

Yes you are right. This containers are hosting Nextcloud. The Fedora is the living one while the Ubuntu is just a dead copy. Meanwhile I have do comparison between vzdump and a backup from the inside of the container with proxmox-backup-client. Duration is nearly the same.

If you can see some thing : Ubuntu : INFO: Starting Backup of VM 101 (lxc) INFO: Backup started at 2020-12-19 12:31:04 INFO: status = running INFO: CT Name: lcdb2 INFO: including mount point rootfs ('/') in backup INFO: backup mode: snapshot INFO: ionice priority: 7 INFO: PYHOOK-PRESTOP...

I have noticed that Debian/Ubuntu container backups two time faster as Fedora CT. To be sure, I have reinstall a Fedora CT with Ubuntu. System install, software install, copy data. Type Distro Size Duration First Backup Fedora 27.02GB 00:45:23 First Backup Ubuntu 23.67GB...

Yes unprivileged. On new Fedora 32 network works too. Probably also with FC 33. Problem only appears after upgrading FC 31 to 32. At least for me on every 6 container migrated.

The first solution was to put a dhclient eth0 in à startup hook script (attached). In a new container with FC32 network works. After comparing new and old upgraded CT the fix was: systemctl enable systemd-networkd-wait-online.service systemctl enable systemd-networkd.service systemctl enable...