Search results

It appears HA changed the nodes in HA group on its own and found the old target vm2408 from somewhere. No idea why. And why was the migration not stopped when there was no propper storage on the receiving node? Why did it not try to migrate it to vm2409? Should the primary host be first? How...

Found this. Very odd.

Something went terribly wrong last night. Apparently one host lost connectivity (because of backup) and HA decided to move the LXC client to the first host on DataCenter list (which does not have same storage.) Entire LXC client just went poof in the air. Oct 13 00:00:17 TASK ERROR: could not...

Hmmm. I think I just made mistake installing sshfs on Proxmox host. The following additional packages will be installed: easy-rsa fuse3 libccid libcurl4 libpcsclite1 libpkcs11-helper1 opensc opensc-pkcs11 pcscd The following packages will be REMOVED: fuse The following NEW packages will be...

Tasks and Cluster log Any change of moving them to right side of the panel? Or better yet how about moving those under the left side pull down menu? We could have one menu for Logs and one menu for tasks. I have always wanted a log for syncronizations and backups to monitor disk I/O.

"It is very likely that the server does not speak TLS at all. The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response...

"It is very likely that the server does not speak TLS at all. The client will start with the TLS handshake and the server will reply to this with some non-TLS response. The client expect the server to do its part of the TLS handshake though. Thus it will try to interpret the servers as response...

They have plenty. The current problem child has 4Gb but usually only uses 1Gb.

Everything on the LXC containers is default except 'nesting' is enabled. Debian is default '12' CT template from Proxmox built using this 'Perfect Server' guide. And the problem is not just with MySQL OOM-Kills but with any service that should restart but does not.

kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ns,mems_allowed=0,oom_memcg=/lxc/602,task_memcg=/lxc/602/ns/system.slice/mariadb.service,task=mariadbd,pid=3269753,uid=100108 My ISPconfig server wont restart any services that have been OOM killed. I'm thinking this is...

How can I find out what container and process is using most IO at certain time?

Same here. FW had a link to old alias that no longer existed. This was logged and gave an error but I did not link it to the problem at first.

This appears to be Intel firmware issue. https://forum.proxmox.com/.../proxmox-random-reboots.../...

Where is this option?

I have been trying to spread the load so to speak after host reboots. Greatest problem now seems to be MariaDB. When all LXC containers start Maria causes very high IO delay on the host. Any idea how to fix that or spread that around (without startup delay)?

Do you mean 5 VMs on Proxmox or 5 Proxmox on your server (using which hypervisor?) I mean exactly what I wrote. 5 KVM hosts most of them hosting Proxmox that are nesting LXC containers. The log snippet I posted was copied from the Proxmox host that rebooted.

There are 5 KVM hosts on that server hardware. vm2405 was the only Proxmox that rebooted. All logs are fed to log server but unfortunately they do not reveal anything suspicious.

I can't explain this reboot on KVM host last night. Jun 09 00:24:01 vm2405 CRON[2014686]: (root) CMD (if [ $(date +%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then /usr/lib/zfs-linux/scrub; fi) Jun 09 00:24:01 vm2405 zed[2014704]: eid=97 class=scrub_start pool='sdd' Jun 09 00:24:04 vm2405...

I upgraded my hosts and removed all SWAP's from the LXC clients and this is the result. Now I wonder if the problem was the code or the SWAP. I'm betting LXC don't like ZFS with SWAP.

Actually I'm using Proxmox FireWall's rather than "Enterprise Firewall" for many reasons. Most importantant is the cluster and the flexibility it provides. It's really simple and scalable. It's client friendly (LXC's are managed by clients themselves.) No need to write a ticket and wait a few...