Search results

So, I'd just maproot (user) to root (IIRC mapall doesn't apply to root in TrueNAS, and I don't think it's a good idea to map to root anyway..), and fix the permissions (chown -R root: /mnt/pve/NAS_NFS once re-mounted). You don't need non-root mounts, as Proxmox will mount as root anyway, unless...

Yeah, it's not that bad, it's indeed the route that drives it to think it has a /8 network. Code is not wrong, but it fails to select the correct (more precise) route, but that may be by design. In src/PMG/Utils.pm it does a proper route check using sub find_local_network_for_ip but if the IP...

How is your interface configured still? EDIT: I'm guessing, properly, as in, as a /16 or /24, I can reproduce it instantly whatever the size of the network configured, pmg guesses "class A! What else could it be!" when using 10.x subnets. I'd say lack of CIDR support here.. and I'd say that it's...

I need to check.. and it may be a "bug" in the way it determines it's own net.. not totally wrong because 10/8 certainly includes 10.10/16 or what not, but not exactly clever. I don't remember how this is computed, but I think that is the issue..

Hi, CIFS should have worked, but well, if you can set up a NFS export, that's fine as well. Can you show us the storage.cfg part about the NFS mount? Maybe also findmnt -u /mnt/pve/NAS_NFS ? Can you check the permissions on /mnt/pve/NAS_NFS/ and /mnt/pve/NAS_NFS/dump ? Also, on the NAS setup...

How are both datastores set up? It seems either the extdrv1 is not mounted, or maybe pbs can't write to it.. but you'd have had an error before the sync job... what does findmnt -u/mnt/extdrv1 tell you? what about ls -al /mnt/extdrive1/ ?

Hi! There is no "SRM", at least provided by Proxmox. But you get internal backups, or you can use PBS. But all that is more about replacing the Veeam part, than the SRM. However, by using PBS, and adding a layer of backup for the hosts themselves, you can easily have a setup that provides DR...

Also.. you mentioned ZFS, but do you use ZFS on root? If so, maybe you are using systemd-boot instead of GRUB, so next question that the latest commands should hint about: do you use secure boot? What does bootctl tell you? You may have missed some feedback from pve8to9, so depending on your...

GRUB sees your kernel now, we have that info. What does proxmox-boot-tool kernel list tell you now? It should see 6.17, and let you refresh the ESP EFI using that new kernel (no need to pin it). EDIT: Ah, sorry.. read to fast. you did that already. Well, what do proxmox-boot-tool status and...

Hmm, it's weird, can you run update-grub ? I'm guessing something went wrong when it tried to configure it.. Or maybe something like apt install --reinstall proxmox-kernel-6.17 Or proxmox-boot-tool commands from @Impact, though it's weird that update-grub didn't pick up the latest version.. but...

Set up your bond, use it directly or through a bridge if you want VMs on it. And either set that bridge as VLAN Aware if you only need VLANs for VMs, or add a VLAN if you want to manage your node through it.. and a bridge on top of it if you also need VMs on that VLAN.. OVS has a few features...

Well, what's in /boot? And what does pveversion -v tell you, and apt policy proxmox-default-kernel proxmox-kernel-6.17 ? I guess installing proxmox-kernel-6.17 will bring it to you, but maybe check further why it didn't update itself.

yeah, but still, obligatory XKCD: https://xkcd.com/1782/

Ahah, well, I'm not too familiar with cross cluster migrations using PDM, and that new-ish conntrack state migration is also not something I really use, so.. I'll have to try it, and look at what the code says.. I'm guessing your setup match the prerequisite.. but maybe the code indeed isn't there..

Good luck, use tcpdump / wireshark to track the issue on the network, -e will give you the ethernet info.. And you can also mark your thread as solved (even though you still have work haha) to let everyone know it's all good.

What does grep pinkdemon /etc/hosts say? or getent hosts pinkdemon ? (or even rg 10.0.0 in /etc, I guess you see where I'm going :P)

I edited my post, it's not on the roadmap, it's on the released features since the 0.9 beta in fact. So there is a restriction / prerequisite that you probably miss there!

Check cloud-init logs, also systemd units failures (other than the obvious network ones), cloud-init is quite fragile. Also, make sure you didn't block DHCP on the firewall, though if the request goes through, it's probably OK.. and check what cloud-init put in the config files.. you're showing...

It's been mentioned on PVE (not PDM: there), so make sure to have matching qemu and qemu-server versions, and up to date ones. I haven't tried production cross cluster migrations, but I saw that conntrack migration is on the changelog for 0.9 beta in the docs and in the Wiki. I will try that on...

Check the status with the commands I gave you hehe, dmesg can also give you precious information. You could also try to bring only one interface up in the bond, or even disable LACP and try to see if the NIC actually works.. also, I hate to consider this, but.. check that everything is properly...