Search results

Are you trying to use e2fsck on a BTRFS subvolume? Can you provide the result of findmnt /? If what I assume is correct, you'll need to check how to resize a btrfs partition, not ext4. Something along the lines of https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html#man-filesystem-resize

I would say that it is like that because nobody uses them that way, so the GUI doesn't really reflect that possibility. Maybe that could be a nice patch to provide? ;) I don't think it's a problem, and you probably don't want all those LUNs to be displayed in the GUI anyway... so it's may need...

There is a qm importdisk command as well, but it probably won't help you in that case, as it wants images, not devices such as LVs. There is room for improvement here on Proxmox though, there could be an option to somehow ease re-attaching disks even from another VM… It would also make cloud...

No, it's not the same. Backup of the VM has the configuration backed up as well as the disk, but maybe you don't care about that, or may be backing that up on your own? And of course, you get all the disks, rather than just one... Then, as for the disk, if the VM is running, the same stuff...

If it works, you could get lucky and if you have a VM with the same VMID your LV is set to, it might be detected as an Unused disk, that you could attach to the VM. That could work... But it probably won't. So create a VM with the same spec in the GUI, with a (or many) disks the same size as...

Hi, You probably won't be able to do this using only the GUI. Add the old disk (or rather its volume group, that should be detected by using pvs/vgs/lvs) as a LVM storage on your new setup, See if you can see them by clicking on the "old" storage, in VM Disks already.

What may not be addressed however, is the fact that the DHCP/NDP rules seem to be set backwards, preventing "client" service when set to no in the options, when the iptables system did it "correctly". There may be room for improvement in the docs, mentionning that DHCP means in fact DHCP server...

This is addressed in https://forum.proxmox.com/threads/nftables-when-output-policy-drop-is-set-on-a-vm-theres-no-way-to-accept-arp-output.146015/

Solution, as it's not very configurable as it is, change proxmox-firewall/resources/proxmox-firewall.nft so that for vm-out it reads: chain vm-out { type filter hook prerouting priority 0; policy accept; ct state related,established accept iifname vmap @vm-map-out }

There are two parts I'm interested in in the nft rulesets: chain output { type filter hook output priority filter; policy accept; jump default-out jump option-out jump host-out jump cluster-out }...

Well, your rules end up with… accept, so it's probably not the same issue, as connection state is probably not directly your issue, I'd say

To summarize the issue, and how to reproduce it. This test was done using IPv6 on WAN, and IPv4 on LAN. - set a CT/VM to policy DROP/DROP - enable port 22 INPUT On iptables/pve-firewall, conf set to: [OPTIONS] enable: 1 policy_out: DROP [RULES] IN SSH(ACCEPT) -log nolog ssh to_ct: SYN...

Hi, I wanted to try nftables on Proxmox, it seems quite nicely done, bravo! I guess most users don't use any output filters, but if using them in iptables, we get a stateful output rule, allowing to only open INPUT for a given port, and assume that it will go out. Chain PVEFW-HOST-OUT (1...

Yeah, I was impacted by that as well on a legacy rule using a legacy ipset (+management => dc/management) and that made proxmox-firewall fail. Fixing it made it start nicely.

It's also true for storage, I have tested adding an "external" SMB storage, if I DROP on INPUT, it's whitelisted, but if I drop on OUTPUT, I get blocked until I add a specific rule to add it. Should I report a bug/try to patch?

Hi, I have code not maintained to do that, around here: https://github.com/gilou/proxmoxthings especially the wol_hack.py thing. No clue if it still works, might need to be updated a bit…

Hi, I noticed that if I set the OUTPUT policy to DROP, I need to add a few rules by default for SSH, migrations to work if I add another ringX address. Could it be that some rules that gets set by default for INPUT may have been forgotten in output ? I see the usual ports...

Jumping in, we do have a PBS instance, rather powerful and well connected, yet the full listing takes 2-5s, while filtering by VMID is a lot quicker. The full list sometimes timeout.. there might be an improvement path there ;)

OK, it works once a VM is started on the bridge...

Hi, Did you ever solve this (without enslaving dummyX)? I do notice the same behavior, even on a public IP, not even ULA… IPv4 works, IPv6 doesn't. Most of the time (aha!). On one machine I have: ip l : 4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default...