Recent content by mdenadal

Thank you for you answer. Yes, sure, but it's not so viable in a cloud setup. So I'll go ext4. Thanks.

Hi, I'm installing Proxmox Backup Server on a virtual machine. The VM resides on a cloud PVE Cluster with ZFS storage. I was wondering which could be the best filesystem for PBS datastores. Nesting ZFS could lead to high memory overhead. What do you think? Thank you. Massimo

Hi Spirit, in my humble opinion Wireguard is definetely the way to go. Way easier to setup and very resilient connections even on poor networks. In the meantime my dirty ipsec setup is up and running since july.

After some tests I saw no performance difference between 1450 and lower MTU. So I stick to 1450 but to be honest I haven't verified if fragmentation occours. From an operational point of view, everything seems ok with MTU 1450.

I manage a 4 nodes Proxmox cluster. Nodes are located in two different datacenters and connected through public network. Till SDN there was no L2 shared between nodes private (aka host only) network. Using SDN (eg. vxlan zones) it's possible to distribute interconnected bridges allowing a bunch...

Arghh..... sorry :-) You meant MACsec ON TOP of vxlan. Yes, this is an option!

Thank you very much for your answer. I fear that MACsec is not an option since it is a layer 2 protocol. My 2 boxes seat in different datacenters. I'll try the ipsec way. If I find an elegant solution I could post a small guide.

Well, connecting 2 remote Proxmox boxes, in example using vxlan tunnels, works really fine. So far so good. I was wondering: what options are there to add a security/crypto layer? Obviously I mean without external devices/apps.

Thank you Thomas. I confirm the patch fix the problem.

pve-manager 6.2-5 (6.2-6 same) seems to introduce a bug with sdn. Creating a zone the zone is listed within nodes items (without icon). Till 6.2-4 clicking on it a vnet lists is shown also allowing to set permissions. After 6.2-5 clicking on it breaks extjs interface. Is this bug known?

Fine thanks! IMHO this is the right way. I can confirm that adding 'auto ...' fix the problem. BTW: other tests are all going fine! (OVS + VXLAN)

Fine, thanks! Yes, sure but this is not required with other nics. Anyway it's enough easy to remember to flag Autostart in the gui.

Found another problem. libpve-network-perl_0.4-6 breaks LXC; container don't start. Was working with libpve-network-perl_0.4-4

Maybe I found a problem. After updating ifupdown2 some nics don't come up at boot time anymore. This is the setup: auto lo iface lo inet loopback iface eno1 inet manual iface eno2 inet manual auto unt iface unt inet static address 192.168.200.232/24 gateway 192.168.200.254...

Thanks for answer. IMHO it's not worth to waste time improving this kind of dynamic switch. What we have now is more than enough. Definetely a warning that switching from OVS to Linux bridge may require a reboot we'll be fine. I'll keep on testing.