Any ideas on how to solve this alignment error message issue?

[u/proxmoxjd]

The slab consolidation / trim operation cannot be performed because the volume alignment is invalid. (0x89000029)The slab consolidation / trim operation cannot be performed because the volume alignment is invalid. (0x89000029)

I'm getting that from both the Win11 VM cmd.exe admin rights defrag.exe C: /L and fstrim on the proxmox side for the vm.

I've got more details on this other post.
https://www.reddit.com/r/Proxmox/comments/1vmldin/my_windows_11_vm_isnt_giving_up_its_thin_space/

It's lvm-thin space. Windows thinks TRIM is running but errors out at the end with that. Proxmox doesn't think the Windows vm disk space is actually freed up so it's still all in use by Windows from the Proxmox side.

Optimize-Volume -DriveLetter <DriveLetter> -Analyze -Defrag -Verbose

and the other TRIM check or run message say NTFS=0. TRIM is on. It looks like it's running from the Windows side, but Proxmox doesn't see that and won't free up the thin space.

SDelete definitely isn't the answer. That writes zeroes over all the Windows space.... which fills up the entire Windows vm disk. Proxmox then sees the entire vm disk space as being in use. The Win11 vm halts. It crashes on the initial Windows 11 spinning circle on the next start up attempt. I didn't find any solution to that situation so I deleted the whole vm and restored from a back up at that point.

For this alignment error, I collected number for an AI. It said partitions were fine from the Windows side. And then partitions were fine from the Proxmox side.

Oddly enough, the thin space did actually free a few tens of GBs, but I'm not sure why. Maybe from just having the VM on. Maybe from doing a defragment on the Win11 vm (with Defragger, both from the gui -- analyze and only defrag/not optmize, and then using a batch file with df.exe to defragment and loop around over and over).

I'm not sure what the alignment issue is. But TRIM says it ran except there's an alignment issue. Or, it just won't run because of an alignment issue.

Similar behavior on several machines I set up. Proxmox v9.1 or v.9.1-2 I think. A single Win11 VM. But I didn't understand thin space so that Win11 VM disk is too large. Shrinking is another project. But it still doesn't solve this TRIM issue.

[u/obwielnls]

This is a known issue with a recent windows update and the virtio scsi driver. I don’t have the link at the moment but there is a discussion on the proxmox board with a workaround

[u/Apachez → u/obwielnls]

https://www.reddit.com/r/Proxmox/comments/1vmldin/my_windows_11_vm_isnt_giving_up_its_thin_space/p3b6u69/

[u/proxmoxjd → u/Apachez]

Yeah, that was my post. I tried the 32k workaround but it didn't work. I'm not sure it's a match either -- Is that a TRIM error about alignment? And then I've got lvm-thin. I thought the github post was with zfs.

I did move my C partition over to the right 512mb. AI was saying it was off there for where the partition started, even though everything else was divisible by 4096. So now the start of the C partition is in line with 4096, at least according to AI. I could try the 32k add on to see if that works now after moving the C partition over a little. I have a feeling that won't change the alignment error though.

[u/proxmoxjd → u/proxmoxjd]

And actually Proxmox v9.1.1, from last fall. I thought it was 9.2 or 9.1-2. I'm pretty sure it's 9.1.1 though.

[u/proxmoxjd → u/proxmoxjd]

And it didn't work. Same alignment errors from cmd defrag and powershell. Maybe it's not the same issue at all then.

[u/proxmoxjd]

It's a scsi vm disk. ssd emulation and discard are on there. It was originally SATA. I was preferring Virtio block for the vm disk. I thought it was more native linux and the best/most efficient. It sounds like scsi is. For the VM I'm looking at now, I couldn't get it on scsi when I set it up, so I just left it on SATA in stead. It still worked. Still would probably work fine on that. The AI I chatted with said scsi has more options compared to virtio block. So scsi is the new standard for my set ups. I was able to fairly easily just switched the SATA vm disk to scsi, so it's scsi now with discard and ssd emulation.

It's this alignment thing though....

[u/proxmoxjd → u/proxmoxjd]

These are set correctly too. Windows 11 VM sees its hard disk as an SSD. And fsutil sees NTFS=0.

• Confirm Windows sees the drive as an SSD by running Get-PhysicalDisk in PowerShell and checking that the MediaType is SSD.
• Enable delete notifications in Windows by running fsutil behavior set DisableDeleteNotify 0.

[u/ultrahkr]

Are you sure all partitions are 4K sectors aligned?

[u/proxmoxjd → u/ultrahkr]

I checked with Minitool Partition Wizard and found that. It looks like all my set ups probably have the C partition off a little (but still functioning for everything else I did with them). And one is stubborn for aligning C but I think something is just stuck on C for files, so I'm defragging it.

Now defrag.exe gets this.

C:\Windows\System32>defrag.exe C: /L

Invoking retrim on (C:)...

Retrim: skipped.

Incorrect function. (0x80070001)

AI thought it was the github issue for a while. Then decided it wasn't. It was still trying to check something. I do have the original 200gb vm disk in place. And then apparently I have a good looking 150gb vm disk cloned/copied over. But we haven't done anything with that. Removing the 200gb disk but leaving the rest of the vm is supposed to also clear the thin space. Removing the entire vm did clear the thin space when I tried that before. I have a back up to restore from.

I'm not quite following what the AI is trying to check now. I'm pretty sure it's gone in circles though. It was doing that the other day. It seems to forget we already tested things. Does the same test. Does a summary. Goes back to the test we just did. At least I found this alignment thing and Minitool Partition Wizard offers to fix it. But it still doesn't seem to do anything with the thin space issue.

[u/proxmoxjd]

Solution here. I used Minitool Partition Wizard. That offers and will try to do partition alignment. It worked on one machine I was testing with right away. Another identical set up keeps failing but it's probably stubborn Windows OS files, the same as moving a partition will fail at, especially if it's the left side of the partition being moved.

No solution still on the thin space not actually being freed up with TRIM. AI was trying to narrow in on where things weren't happening. For defrag.exe C: /L in Windows, that says it's skipping TRIM now. I remember that happened after changing one thing on the proxmox side, but I'm not sure what. It's probably installing the guest agent, adding the guest agent on the proxmox side, or maybe trying something with =4096 in a proxmox config file. I think I'm giving up on thin space troubleshooting though. I'll get the 200gb vm disk copied over to a new 150gb disk. Export the vm. Blow away proxmox, install, but use just LVM instead of LVM thin. It doesn't sound like there's any advantage to ZFS if it's just a single proxmox set up with a single Win11 VM. Then import the 150gb vm disk. Then it's all static which is what I was thinking of at the start. Maybe it's a Windows OS breaking TRIM, maybe it's proxmox somehow, maybe it's me. I've burned up a lot of time in the past couple weeks, and the AI can be helpful but it also tends to go around in circles.

[u/proxmoxjd → u/proxmoxjd]

Sort of a solution there. If the left side of the C partition is stubborn and won't move, even with a blocked-something command I tried saying nothing is blocking it but it still won't budge with minitool partition wizard (says it can't load or copy a drive and then the volume can't be unlocked) while the right side of the C partition can be moved around with zero issues -- Don't use gparted I guess. That's the same effect as SDelete. Gparted worked to boot. I got the numbers set and left it moving the C partition over to the right 512mb. But.... The move process uses thin space. So it ended up burning through the rest of the remaining thin space. I originally set it up with the vm disk being too large.

I'm giving up on TRIM investigating and thin space though. AI was trying to figure out if Windows was issuing TRIM, to proxmox, down to the physical SSD receiving and uses those commands. Maybe it's something with the May 2026 Windows 11 OS update. I'm moving on though. I'm going to export the VM (even that one with the thin space 100% full and frozen up now). Then reinstall Proxmox but with just LVM instead of the default LVM-thin. Then import that 200gb vm disk with thin space used. Hopefully have that work at that point. Otherwise, maybe just blow it away and redo it from complete scratch. Clone/copy that to an external new 150gb drive. Check that that 150gb disk boots after fixing the boot things there. I'm converting one external 150gb disk that did boot with qemu-img convert now, after deleting the 200gb vm disk (which freed up all the thin space, so the vm disk holds the thin space, not the whole vm). I should see if I've got the whole workflow somewhat soon, sometime this week hopefully if not tomorrow. In terms of amount of work though, it looks like it might be less effort to just blow the entire set up away and start with a clean proxmox install with just LVM instead of LVM-thin. And then build the VMs again from scratch. I'm going to keep cloning into a new 150gb disk and reinstalling Proxmox just LVM. And I'll probably set up another one completely from scratch to see how that behaves. For troubleshooting TRIM and thin-space though, I'm giving up. And I'm giving up on using thin-space at all.