Search results

We have done some more experiments with settings. If I increase the CPU's on this machine to 30, the problem of "D" state processes waiting for the disk practically goes away. However, while this may be a partial workaround, the problem is still that the CPU usage is way too high. The process...

This problem has been re-occuring repeatedly... new thread here

Yes, this has been an ongoing problem. When we moved the storage to non-ceph lvm-thin storage, the problem seemed to go away. However, after a couple of weeks it started re-occuring exactly in the same way that it was on ceph rbd storage. There's no specific time. We have had a completed...

Reading the whole tread will be helpful. The nvme1 is part of a ceph pool, but the problem occurs regardless of which pool the VM uses, even if I move it to a local ext4 lvm-thin volume, the problem still occurs. Many other virtual machines are using that pool and they don't have any issues.

I changed the thread name to better describe the issue.

Ok, the user has started his machine again at just after 15:00. syslog has been attached. # pveversion -v proxmox-ve: 7.4-1 (running kernel: 5.15.108-1-pve) pve-manager: 7.4-16 (running version: 7.4-16/0f39f621) pve-kernel-5.15: 7.4-4 pve-kernel-5.13: 7.1-9 pve-kernel-5.3: 6.1-6...

As to the size shown issue: Can we have this flagged as an inconsistency to be fixed in an upcoming version? Either the aim should be everything in GiB (prefered?) or else everything in GB. As to the host logs: I'll have to wait for it to happen again and will post it then

The vm config shows 130GB allocation for the disk. sata0: speedy:vm-199-disk-0,discard=on,size=130G,ssd=1 The guest is FreeBSD, fsck has been run very often, that's not the issue. The problem is that the processes are running into a "D" state (waiting on disk). Eventually nothing runs on the...

We're experiencing a problem with a FreeBSD KVM guest that works 100% on installation, but after a while starts complaining that it can't write to the disk anymore. What we have done so far: Moved the disk image off ceph to a lvm-thin volume Changed the disk from Virtio-SCSI to SATA and also...

Found it, thanks to someone on Reddit: dmidecode --type memory | grep "Maximum Capacity"

Scenario: Centos Guest OS with 8GB/24GB RAM as min/max allocated. The machine typically uses between 10GB and 12GB of the allowed RAM due to ballooning, but here's a problem: Using free -h shows only 14GB in total available. Can't find anything else that shows the 24GB max allowed. There are...

I'm getting the error below after something happened (it was not happening before) and not sure that I changed anything deliberately. It prevent the status graphs (rrd, right?) to be displayed on the PBS administration section. Oct 11 22:07:17 pbs3 systemd[1]: Starting...

Thanks for this, @Chris! I have implemented a local PBS and will be running sync jobs to pull the backups off-site. I see how it goes in the next few days.

I have run into an issue a couple of times in that guest OS's slow down dramatically if the PBS server doesn't perform for whatever reason. Previously I had a network issue, which prevented backups from being written at a reasonable speed and it caused the guest machines being backed up to...

From the pfSense on NodeB, I can ping a VM on nodeC on VLAN12, which then mean it is actually working! There is not other way to that a ping from 192.168.161.253 (pfSense VLAN12 gateway on running on NodeB) could reach a VM on NodeC! Since I have only done the changes for Node B and C, testing...

Maybe there's a problem with these SDN ports in pfSense. I have 2 pfSense VM's that act as router firewalls. The default gateway on each network an SDN interface on these pfSense machines. It's actuall a CARP ip address that "floats" between the two firewalls and redirects to the actual...

NodeC:

I had to rename them with .txt extension to be able to attach them here. These are NodeB, NodeC to follow...

Just a bump... @spirit: The SDN is still not working despite the change to a name that is recognized by the code...