Search results

Interesting findings, but how to deal with them? Neither the host nor the container seem to have ACL enabled on their respective file systems. I've restored ~20 OpenVZ containers and each of them now has (probably weird) ACL set all over the place. Should I deleted them all? In fact, can I...

Thank you, I've created a gist: https://gist.github.com/datenimperator/48a92edf035c37511ce2

You're right, thanks. I've got it installed: $ uname -a Linux s6.domain.example 4.2.6-1-pve #1 SMP Sat Dec 19 15:42:50 CET 2015 x86_64 GNU/Linux It's up since 30 hours but still my LXC running gitlab is driving me nuts… anything I need to do in order to get this going again?

@tom if you could enable that fix any time soon, even if it's only temporary, that'd be great.

Should I wait for the fix to land in subscription land or is it advisable to install that kernel manually?

In fact it's even more sockets involved: /var/opt/gitlab/gitlab-rails/sockets/gitlab.socket /var/opt/gitlab/redis/redis.socket /var/opt/gitlab/gitlab-workhorse/socket

Thanks for your tests, that sounds encouraging. Maybe Proxmox staff can spot a difference in the source code?

I'm experiencing issues with PVE 4.1, AppArmor, LXC migrated from OpenVZ and various services that use UNIX sockets for communication, like mysql. Have you tried setting lxc.aa_profile like described here? Permission error w/ sockets inside CT since migration to PVE 4.1

I assume there were good reasons for Proxmox staff to drop OpenVZ in favor of LXC in PVE 4.0. Being able to run a fairly standard kernel instead of a heavily patched OpenVZ kernel might be one, I guess. That being said, I learned that I manually need to add a custom parameter lxc.aa_profile...

Due to lack of appropriate testing hardware, I migrated one container to see if importing a backup works, which it did. I did not start intensive functional testing beforehand, because I assumed that Proxmox tested its release software better than I did. In particular I expected LXC to work...

Yes, containers, not hosts. Sorry, my bad.

The same is true for socket based communication eg for mysql servers. This is ridiculous: Migrating perfectly working OpenVZ containers to LXC renders at least one service in each container unusable. Does disabling AppArmor help? How would I do that, given the fact that PVE 4.1 lists AppArmor...

I've added that rule unix (create,bind,listen,send,receive) type=stream, to /etc/apparmor.d/lxc/lxc-default, reloaded AppArmor and restarted one container. It didn't help. :-(

Does this render AppArmor, LXC and PVE 4.1 somewhat unusable? Or: How is this supposed to work when migrating OpenVZ containers?

I've seen AppArmor errors regarding postfix and others, but nothing about sockets. Here's /var/log/messages while starting a LXC: Dec 20 17:41:25 s6 pct[23333]: <root@pam> starting task UPID:s6:00005B26:001E52C8:5676DA35:vzstart:106:root@pam: Dec 20 17:41:25 s6 kernel: [19890.792165] IPv6...

I've already added the stance to /etc/pve/lxc/<vid>.conf and can confirm that is is included in /var/lib/lxc/<vid>/config, too. I'm not sure about aa-status, though. My process list shows [lxc monitor] /var/lib/lxc 210, which is parent of an init process at run level 2. I assume thats init of...

I've migrated a number of hosts from PVE 3.4 to PVE 4.1 and I followed the instructions (stop CT, backup CT, copy backup, restore, reconfigure network). Most of my hosts use an internal init script to start an application server. That application server creates a socket, to which an internal...

Hi, I'm about to migrate a Proxmox VE 3.4 host to 4.1. I'm starting with a fresh 4.1 install on separate hardware. What's the best way to migrate OpenVZ hosts with minimal downtime? I understand containers need to be stopped. So downtime needed for the migration sums up to shut down the hosts...

I'm using Proxmox VE on Debian 6. The machine (a Hetzner dedicated server) has a Realtek r8168 NIC, the standard r8169 driver gives me all kinds of strange errors. Thus, I've added the sources from Realtek to be compiled using DKMS. This works flawlessly using kernel 2.6.32-17-pve, but I can't...

This has been asked before but not answered, so I need to ask again: Can a container have both a venet IP address as well as a veth network interface? Or: Do I even need that? My setup looks like this: vm1 and vm3 should have two ethernet ports, being able to access vm2 and vm4. I was...