Search results

Rebooting the nodes got the new microcode into the Kernel. Or at least it seems to have... Unfortunately it's looking like hot-patching CPUs isn't supported in Proxmox-VE. The Proxmox-VE kernel is compiled without CONFIG_MICROCODE_LATE_LOADING. The short version is that microcode can be...

See also this proxmox wiki page: https://pve.proxmox.com/wiki/Storage:_LVM_Thin

What "pvdisplay" shows is a physical volumes and doesn't show whether or not you're using volume thin provisioning. What does "lvdisplay" show? This will show if you're using lvm thin provisioning or not

I haven't, I got busy with other tasks and I also figured "time may fix it". We have a shiny new proxmox cluster I might be able to try things out on (that will have support on it). I'll report what happens, though it may be a few weeks in the future.

I determined that it wasn't necessary to set this value. Most people use LVM thin provisioning. To quote @fabian, If you do use LVM thin provisioning, you can always edit /etc/lvm/lvm.conf to insert this line: issue_discards = 1

I'll give it a try, but these are AMD CPUs

I'm having a weird issue getting the firmware loaded onto a system and I'm not sure if it's related or not. I installed all updates on proxmox-ve 8.0.2 (pve-no-subscription repo), rebooted and I'm still seeing some warnings in my logs. root@pve2:~# journalctl -k --grep=microcode Aug 14...

For completeness, a fresh install from the 6.4-1 ISO (which installed the proxmox-ve:6.3-1 package) had issue_discards set to 1. root@pve-test:~# lvmconfig --typeconfig full | grep issue_discards issue_discards=1 root@pve-test:~# grep issue_discards /etc/lvm/lvm.conf #...

Ah that makes sense. Thanks for clarifying @fabian Not relevant to this forum but kind of curious as to why Debian doesn't default this to on.

You know... When I installed 7.4 (from proxmox-ve_7.4-1.iso), the defaults are to set issue_discards to 0 as well. This system was originally a 5.x install and I've done several upgrades so I'm wondering if it was a setting from a long time ago. I don't believe it's anything I tuned myself.

I had a chance to do a fresh Proxmox-VE install (inside a VM if that makes any difference). The defaults are to leave issue_discards set to 0 (off). The install was using proxmox-ve-8.0-2.iso. root@pve-test:~# lvmconfig --typeconfig full | grep issue_discards issue_discards=0...

I absolutely got the prompt and selected the package maintainer's version following the wiki instructions: https://pve.proxmox.com/wiki/Upgrade_from_7_to_8#Upgrade_the_system_to_Debian_Bookworm_and_Proxmox_VE_8.0

Hi, I'm not sure if this is an "issue" per-say, but I noticed that during an upgrade the `issue_discards = 1` config line is removed from lvm.conf and the new default is `issue_discards = 0`. I also could not find the setting anywhere else in /etc/lvm, for example in lvmlocal.conf. Is this an...

TY; this was my issue as well

That's probably my bad -- I see it there now. I think I got ahead of myself when writing the post.

I had a problem upgrading from 7.2 -> 7.3 on my home machine. I think a reboot will fix it, but I want to report it. Is replying in-thread the correct place to do this, or should I start a fresh thread?

Putting the cloud-init drive (ide2) in the boot-order seemed to do the trick. This is available via the API, but not via the WebUI. Were you thinking that having it in the boot order initializes the IDE device? Testing Results Note that on all subsequent tests below, I made some changes...

Interestingly enough, it won't let me. I don't think I can add CloudInit drives to the boot order (see screenshots below). At least it won't let me through the WebUI. I do want to take a moment to clarify that I'm not actually trying to boot off the CloudInit drive. I think you're aware of that...

Thinking through this a bit, I'm really doubting this is a proxmox-specific bug. In my head I'm imagining it being one of a few things 1) Qemu IDE device bug 2) Kernel bug regarding this IDE devices 3) an issue with how distributions are building their devices. It seems like it *could* be a...

I tested out a few different cloud images. What I found intriguing, but also confusing is that Several distributions exhibited similar behavior, but ever so slightly different Changing to SeaBios fixed the issue in SOME cases Increasing the core count made it WORSE in some cases Images used...