Search results

I see. so you really do have two independent iscsi hosts (targets.) There should not be any conflict between the two pools. post logs (dmesg, iscsiadm -m session, lsblk, etc) for the host with the failure and we can go from there.

a SAN would be a shared device of some sort. when you say you have "two" SANs, do you mean you have two boxes serving independent iscsi luns, or two boxes in a failover capacity (meaning one set of luns?) In either case, this becomes a simple matter of mapping iscsi luns to your cluster. I...

post the contents of /etc/network/interfaces for all 3 nodes. also double check each machine's hosts file and make sure they contain the same records for all 3 machines, and that they all match the output of hostname for each.

I feel you. this leaves you with 2 options- 1. do not use pveceph. which you totally CAN 2. open a feature suggestion here: https://bugzilla.proxmox.com/enter_bug.cgi

Your issues are larger then can be corrected with dpkg/apt. you have two choices here: 1. regress EVERYTHING you did on this system (software installed, kernel line arguments, etc) until you can have that command complete without blowing up your computer 2. wipe and reinstall, and pay attention...

I got nofn...

ceph usage gives you raw utilization numbers. if you use ceph df detail it will give you actual statistics including compression (which I suspect are the cause for the difference between du and df)

the one other factor that could be at play is the size of your pgs. how many pgs in the pool and whats the raw capacity?

Disable acpi extended modes in bios.

remember to trim your guests

This can be done without any downtime. and yes, you want to make sure that the running ceph version is available on the next distro- so make sure before you start you upgrade your ceph to squid. This process is non disruptive and will not introduce downtime. see...

that should be your first option ;) PVE8 is not EOL yet, and even when it is (this august) you can keep running for some time after. might be the better option, especially if you dont need anything pve9 specific. This will give you time to figure out the issue on a pve9 testbed before...

so here's what I'd suggest- dont use 10.13.30.x for corosync at all. assign arbitrary addresses to bond0 and bond1; --edit- ON DIFFERENT SUBNETS. ideally, they should be on seperate vlans too. use those addresses as ring0 and ring1.

@UdoB correct. I started typing add blah blah blah but the changed it to an echo. hilarity ensued.

This might help: https://forum.proxmox.com/threads/yawgpp-yet-another-windows-guest-performance-post.181030/

sudo apt-get -o Acquire::ForceIPv4=true update to make permanent, echo "add Acquire::ForceIPv4 true" >> /etc/apt/apt.conf.d/99force-ipv4

then you need to use QOS and/or limit the bw of your backups. this will happen again.

are you sharing interfaces between PBS and corosync? if so, break them up.

assuming the logs provided are up to the time of death, this is the likely cause. are you backing up to an NFS target?

post the content of your /etc/network/interfaces files. note which interface is being used for what purpose.