Recent content by Don Daniello

@dcsapak So that looks like the crux of it. Passing rootfs: local-zfs:5 seems to be doing the trick. The interesting part is that apparently I've been using it wrong for 7+ years but it worked all the way until now as non-root. I have to say, the documentation for rootfs parameter...

@oguz I've made a few important discoveries. First, I realized that PVE API returns error message in the "status line" of HTTP response. That was my mistake to not realize it earlier and to be honest, I've never seen an API server actually do that before. Therefore, I kept being confused by...

Yes, nodes were all rebooted after upgrade to PVE7. Not all nodes were rebooted after latest minor kernel update, I doubt that matters. I've also tried rebooting the node in question, which did not help. What's new is that prior to installing latest set of updates yesterday and prior to...

The request is sent from a nodejs app via HTTPS API remotely. There is nothing in journal related to that request. However, I am certain it is reaching that server since pveproxy on it shows the request in the access log. The versions are all the same, all latest:

Hello, I seem to have an unusual problem which happened shortly after upgrading to PVE 7. I have an application which creates LXC containers on a PVE cluster over API. Recently, it started getting 500 status code in response to POST /api2/json/nodes/node1/lxc. The response body does not have...

It looks like both the symlink shown by @victorhooi AND installing apt install python3-distutils are needed to make out-of-the-box Ceph on Proxmox actually work flawlessly.

I had the same exact problem. My error exactly: Turns out the container was configured with eth0 using vmbr1, which didn't exist and should be vmbr0 instead. Upon changing the network setting, the container started up immediately with no errors. It appears the error message is very misleading.

I will keep an eye on this report and add my setup if it happens again. So far it only happened once after 90 days of uptime and we use bult-in PVE replication a lot (every 15 minutes for many LXC containers) using ZFS send/receive of course.

I seem to have a similar issue but the stack looks like this: root@ex1:~# cat /proc/1005172/stack [<0>] taskq_cancel_id+0xdb/0x110 [spl] [<0>] zfs_unlinked_drain_stop_wait+0x47/0x70 [zfs] [<0>] zfsvfs_teardown+0x25/0x2f0 [zfs] [<0>] zfs_suspend_fs+0x10/0x20 [zfs] [<0>]...

The rules do compile. Everything is applied fine from PVE side of things. I can see the rules configured in iptables, nftables, ipset, etc. The only problem is that the kernel does not even process packets through them because of net.bridge.bridge-nf-call-iptables=0. There should be a mechanism...

I enabled it at all those levels and set the rules at the VM level. There are other rules set at other levels but I'm not expecting those to apply now.

@mira The firewall rules are obviously configured via the PVE web interface, it is the PVE firewall after all. If bridge-nf-filter-vlan-tagged doesn't get set then the setup I described above wouldn't have firewall operational. However, I queried the status of all those sysctl settings and...

Thanks, this worked for filesystem-3.2-21.el7.x86_64 on CentOS 7.

In most cases where IPs are routed through the PVE host, the bridge-nf-call-* settings do not need to be enabled for PVE Firewall to work. However, we have recently switched to using a vlan-aware bridge on the host and configure the VLAN ID directly in Proxmox for each container/VM interface...

You can easily ask for a 3 hour KVM access and send them a link to ISO to be burned on flash drive and attached. They'll happily do that every time for free, that's how I always install my Proxmox servers.