Search results

In terms of ECC memory failure, the proxmox log will start recording the ECC corrections, and the stick/slot which is being affected; I had this happen. I've not encountered a faulty CPU report in Proxmox, but that goes into "mystery freeze/crash" territory when it happens. Diagnosing it is...

If possible, could you sketch up a diagram of the layout? It'd make your situation easier to understand.

Fortunately, you can configure this from the proxmox shell view of the CT. So, we're lacking a bit of detail here, but here's what you need to look at: 1) /etc/ssh/ contains the configuration files for ssh; one of them will be sshd_config 2) we need to see that configuration; could you post...

So, one of the problems that can happen in a forum is asking 64 questions to reach a final answer. Not because asking is bad, but because asking for all the information at once does not result in the information being given. So, you know what? People reading the thread can work really quickly...

Oh, that error, yes, that's what I encountered. It would hard-lock the array, resulting in data loss, when the array was subjected to heavy writing. Ultimately, I had to run the ZFS pool using the rescue option, then copy the entire VM from the pool to a specially bought external HDD...

Can you tell us more about the host system? [Does it, itself, have NUMA running?] Total shot in the dark, but worth investigating.

If it complains bitterly, you could try importing read-only, to rescue the data: sudo zpool import -f -o readonly=on [poolname] -R /mnt/[poolname]

If the VMs are Ubuntu or debian, for example, then there is the unattended-upgrades module, which has a configuration file at /etc/apt/apt.conf.d/50unattended-upgrades https://wiki.debian.org/UnattendedUpgrades But yes, as LnxBil says, it will be a per-distro thing. You could always write...

Also, see this thread: https://forum.proxmox.com/threads/ho-to-increase-local-size-and-reduce-local-lvm-size-in-same-disk.124172/

So, what I see in the screenshots indicates a cluster, which is likely using CEPH storage. As CEPH storage will be shared between the nodes, this means each system using CEPH storage for its disks will write to all nodes. That requires the usage of the network for this to happen and is why...

Okay, something has not quite gone right there, as it's attempting to write to an area which is located where the old partition used to extend into. This is very bad, and the main thing is we need someone who has seen this before to chime in. What order did you do the resize in? Did you resize...

Ahhh, now that's one I'll file away in the "check this" list. By the way, have you checked if the BIOS battery is providing enough volts? Just in case fluxing power from it causes the BIOS settings to silently corrupt over time? @ccigas That BIOS reset might be worth investigating too, but...

Did you shrink the volume?

What you describe there sounds like a saturation problem. What is the networking infrastructure for the cluster, and is the backup system separate from it?

Okay, how about this, you can edit the Install Proxmox grub line (e to edit) and add the following kernel parameter: nomodeset In the below example, I pressed e with the install line highlighted. I have typed nomodeset on the line called linux. It will then boot if I press F10.

Perhaps we need to get back to basics; what is the hardware you are installing to? [I've had bad things involving hardware drivers before, and had to tell the kernel to use fbdev in order to see things, but that was with SuSE TumbleWeed on some very old rack servers.]

So, in theory, the VM in your example resumed: INFO: resuming VM again Initiate Backup->suspend VM->Prepare Disk for Snapshot->Snapshot->Redirect writes->Start VM. Check the ones which failed. Do they all say "VM Resumed"? I'm wondering if it's a race condition, as that would produce the...

Yes, think of the exporter as the information agent. You install an exporter node on each machine you want to monitor. Then, you tell Prometheus to scrape information from each of the nodes you installed. Graphana can then be configured to query Prometheus for that information. In terms of...

For comparison: As you can see, the vmbrX entries are where the action is at.

It's all the page faults, seg faults and so on in the log which stand out to me. Personally, I'd say something is up with paging, and that'll be memory. Okay, a surefire way of ruling it out would be to test the setup with a different set of RAM sticks, if possible, to see if it makes a...