Search results for query: Thunderbolt 6.8

Hi, I just set up a ceph ring mesh network on 3 nodes using the "simple routed setup" from the guide you posted (2 TB ports on each node, connected to the other 2 nodes), and I was wondering the same thing about using a spare ethernet interface connected to a dedicated switch as failover or even...

pvestatd is failed again. Please tell me if I should debug specific logs / services. Unless I'll keep posting error messages.

Like many of you have a thunderbolt mesh network that uses openfabric frr to create a routed topology. I use IPv6 for ceph on that mesh along with IPv4 for other traffic (like pve cluster traffic). I wanted my docker swarm VMs to be able to access the cephFS file store. I am using virtioFS but...

I had a weird cephFS issue i couldn't source the root of. i only noticed it on the two nodes that had opt-in 6.14 kernels, that could just be coincidence. I have reverted to the 6.8 kenel on those two nodes. I am back working but want to do some log archaeology to see if i could figure out what...

the scenario i am trying to acheieve is the simplest way to get a VM to be able to talk to my ceph public network (which is isolated on the thunderbolt mesh network)

for the VM connectivity issue on host <> VM it isn't, also the underlay has both a IPv6 and IPv4 openabric routing so we get frr paths, but it may be causing other issues - I have yet to get a VM talking to the host IP's that are purely on the thunderbolt mesh - though i see others have done...

I have been playing quite a bit with frr and sdn over the last few days, I was having really weird unreliability with my cpeh thunderbolt mesh network. I eventually traced it to the the fact that: i set the loopback interface IP addresses with frr (instead of a /etc/network/interfaces file)...

ouch, no, each node got a version of this error and frr did not restart, luckily restarting frr.service got my old openfabrice backup whats interesting is it errored on my real IPv6 address assigned to vmbr0, not the addresses defined in my thunderbolt net or the SDN Oh i see it expected 4...

interesting tutorial - i am hoping this can help me expose my thunderbolt mesh network (used for ceph public and cluster). i have 3 node thunderbolt mesh based on this guide it works great this is the existing openfabric routing on each promox node, where X is the node number. (note i only use...

Thanks, i am trying some alternate apporaches given my main ceph network (that is working) is inherently private due to the thunderbolt-net mesh first approach will involve expanding/extending the frr openfabric routing i use on the thuderbolt-net mesh onto the LAN by including br0 in the frr...

I have 3 nodes they have: public interfaces facing the LAN thunderbolt-net interfaces connected in a mesh ceph configured to use the mesh as its public and private networks for purposes of this scenario testing all firewalls on VMs Node1's private addresses are: 10.0.0.81/32 fc00::81/128...

Ok, i am starting to think this is a network issue - probably with routing in the proxmox node linux kernel - but i am stumped as to what give ICMP defintely works in my /etc/sysctl.conf i have this, i thought this allowed for full IPv4 and IPv6 routing.... net.ipv6.conf.all.forwarding=1...

you need 3 nodes my 3 node cluster is comprised of intel NUCs, with one NVME for ceph in each networking is ~26Gb/s (thunderbolt mesh) and it uses so little of that... i know of folks who had small envs on 2.5Gb/s all that matter is the realtime load, boot storm loads and amout of data that...

Your ancdote led me to a new idea: Is it possible to do replication between Ceph storage and ZFS? Then I could use the third single disk for Ceph and define a replication from this Ceph storage to the ZFS storage. Expected result: As long as Ceph is working I have real HA. If it fails somehow...

It's the same with QLC and SMR drives: nobody buys them after searching the forum, always the other way around... Proxmox is based on Linux and you need to research support before buying any hardware. I have no personal experience with Thunderbolt/USB4, so maybe it still works for your use case...

Passthrough of Thunderbolt does not work (as well) as people hope(d) it would: https://forum.proxmox.com/search/8333523/?q=thunderbolt&t=post&c[child_nodes]=1&c[nodes][0]=16&o=date

Hello all, I have a PVE server that has a TBolt 3 connection. I am thinking of getting a Thunderbolt 3 external NVMe enclosure and connecting it to my PVE server. The goal is to create an UnRaid vm, with access to the external enclosure. I would assume I would need to fully pass the external...

Everything needs to be on the same/first line of the file: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysboot_edit_kernel_cmdline

thats def the issue I think. root@proxmox2:~# efibootmgr -v BootCurrent: 0003 Timeout: 3 seconds BootOrder: 0003,0002,0004,0005 Boot0002* Linux Boot Manager HD(2,GPT,d4997aee-7911-4f52-8797-f70642d75c04,0x800,0x200000)/File(\EFI\systemd\systemd-bootx64.efi) Boot0003* Linux Boot Manager...

It looks like the boot option thunderbolt.host_reset=false isn't in being passed to the kernel on boot. I just can't see why. what file should this appear in?