Search results

Looks like https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779

`them in` typo corrected... Open eg. /etc/pve/qemu-server/100.conf, look for (or add) the line starting with `cipassword: ` and put the password there in plaintext like cipassword: 12345678

For configuraton errors / faster restore, you should use snapshots. `data` there is a thin pool supporting snapshots after all. If you still want to allocate some space for a directory storage, you can just as well create a thin volume on that data pool with the size you would otherwise want to...

Were there also updates to the container inside? With lxc.apparmor.profile the apparmor errors shouldn't happen, and the log shows you're using the regular profile still. Does the log output change after using lxc.apparmor.profile?

Not yet. You can add a profile manually for now, eg. # /etc/apparmor.d/lxc/lxc-default-cgns-with-nesting profile lxc-container-default-cgns flags=(attach_disconnected,mediate_deleted) { #include <abstractions/lxc/container-base> #include <abstractions/lxc/start-container> deny...

This is currently not handled as the lines are added unconditionally to the config file. I posted a patch to deal with this to the devel list for review.

cloud images are usually configured to resize to the disk size at boot time, so it should be enough to just use the resize button in the gui before booting the VM

You need to install the wireguard kernel module on the host first. There are wireguard-dkms packages in debian unstable you can build. They seem to work fine.

For the network settings there's an update queued. For the passwords - that's because when setting them over the api we only store hashes, and CentOS 7's current cloud-init version does not support pre-hashed passwords, only plaintext ones. Currently you can only write them in plaintext manually...

Prinzipiell kann man das schon machen, muss aber explizit auch die metadaten volume mitvergrößern. Das passiert leider nicht automatisch.

If this is still reproducible, can you please try running it with PERL5OPT='-MCarp=verbose' set? Edit: nvm, not needed, sorry for the noise.

I'd bet on that. Also note that LXC has nothing to do with the way swap or zswap is implemented in the kernel and no: lxc is not a kernel feature. All lxc does is configure the cgroup limits which are used by the kernel to make decisions. If the kernel implementation of swap-limits means the...

When adding via `pct` try using `--ostype unmanaged`

It does sound like simply setting the vlan option on a VM's network interface does what you want. Whether or not there will be separate bridges for each vlan tag depends on whether you configured your bridge to be vlan aware. If you want all traffic to go over a single bridge, check the 'vlan...

The ebtables support is currently mostly a backend change and some improvements are still planned. Eg. you currently cannot add custom rules and due to the way the command line tools work it doesn't currently integrate well with manually managed rules (but we'll work on that). As for the...

The only thing you really can do (and should do anyway) is to use /dev/disk/by-id,label,... (I have a system where not even the sata slot numbering found in sysfs stay consistent across reboots...)

Meh. I guess we can look into that. I still want to point out that it totally defeats the purpose of the whole cloud init project and having to workaround differently-broken variants of it that way is completely insane.

If you want all users in sync on both host and all guest systems, it's the same as when you have a bunch of physical machines. You can ignore the fact that they are VMs or containers. So yeah you probably want to setup ldap or NIS. Both take some effort to get into and setup at first.

@conrad784, ebtables runs in addition to iptables, if your iptables are empty there must be some other issue, you should check your rules and logs. @arteta, that's a different issue, you already had ebtables rules which now get replaced - please open a feature request on our bugzilla

Yes, unfortunately. But I'd much rather have them fix it. See, if we fix distribution A it might break distribution B and vice versa... it's been quite frustrating...