Search results

I can recommend using OmniosCE. Have been running it here for more than 10 years without any problems or issues just remember to separate iSCSI traffic on a different network than the network for proxmox cluster. Preferably using 10Gbit or better is using it in an enterprise setup.

A question: Is it the optimal way that mounts should be blocking? Would it not be better if mounts was not blocking and used a timeout instead and in case mount observed timeout refuse starting VM's/PCT's with block devices on these mounts?

Sorry, missed that info ;-) New information: Only problems with NFS mounts to Qnap. NFSv4.2 does not work NFSv4.1 does not work NFSv4.0 work NFSv3 does not work.

As can be read here: https://forum.proxmox.com/threads/proxmox-ve-7-2-released.108970/post-468736 kernel pve-kernel-5.15.30-2-pve does not fix the issue. As a remark I have a Qnap which have a iscsi and nfs mount but have other storages as well but apparently if the Qnap mount fails the GUI...

pve-kernel-5.15.30-2-pve completely brakes GUI functionality. The cluster works as expected and can be managed via CLI on the different nodes (stop, start, and migrate - also VM's running in HA mode) but no way to do it from the GUI. Booting nodes using pve-kernel-5.13.19-6-pve and the GUI...

Not only that but if you run micro services or docker based services spooling a complete operating system is a waste of ressorces. Only if your micro services or docker based services must have a 100% uptime then go for a VM since LXC containers cannot live migrate still.

So you convert from unprivileged to a privileged container, sounds contradictory to me:rolleyes:

I think that part is from a time where unprivileged containers was not production ready and default was to run using a privileged container. A privileged containers root is mapped to the host root so breaking out of the container means that you get root privileges on the host while breaking out...

The easiest and safest way is to make a backup and restore it given the VM a new id.

From https://[your_pve_host]/pve-docs/chapter-pct.html#pct_options: keyctl=<boolean> (default = 0) For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container. By default unprivileged containers will see this system call as...

You are correct. Using https://pve.proxmox.com/wiki/Unprivileged_LXC_containers to convert from privileged to unprivileged container. Though, if you have disabled login as any user including root with password and only allow certificate based logins should narrow safety down ;-)

You need to run in a privileged container. By default a LXC container is created unprivileged. See here: https://forum.proxmox.com/threads/docker-under-proxmox.81618/post-360134

Is it this you want? docker run -d \ --name nginx-proxy-manager \ -p 80:8080 \ -p 81:8181 \ -p 443:4443 \ -v /Docker/nginx-proxy-manager:/config \ jlesage/nginx-proxy-manager

I have read numerous times that people request support for Docker in Proxmox so I use some time yesterday to find a solution. The basis for the solution was this on Youtube: https://www.youtube.com/watch?v=79KiCBNbsbg I have tested his solution and it works great - I have decommissioned my home...

To me it sounds odd that you can give all permissions to a user/group but then again all != all. Why can root@pam not give any permissions to a user/group? This is contradictory to how permissions work in Linux/Unix.

Hi all, I have created a group named admins. This group has the following permissions: Path User/Group/API Token Role Propagate / @admins Administrator Yes I have assigned a user which login through ldap to this group. I have even...

These are just warnings and of no concern.

This package was pushed to stable yesterday: libpve-storage-perl (6.2-9) over (6.2-8) Maybe there is something in the patch(es) in libpve-storage-perl (6.2-9) which solves some or your problems?

Sounds reasonable. Thanks.

But now it is you Stoiko who is responding. I was actually trying to ask you a question on the pve-devel list: On Mon, 12 Oct 2020 17:34:56 +0200 Stoiko Ivanov <s.ivanov@proxmox.com> wrote: > This patchset follows the fix in > 609f117ff24d2cff6b155e1d4b1175ceebe5bd7b. Since several operations...