Based on your other thread I don’t think the disk is partitioned in the way it normally would be, looked to me like you ended up passing through a partition instead of the whole disk. Please provide
fdisk -l output for the disk in question.
P.S. Would recommend passing through your entire SATA controller if that’s possible, that way everything works and operates like normal in a dual boot scenario because it will use the same driver for the controller instead of using like a VirtIO SCSI driver for VM and actual controller on bare metal. I used to pass through my entire disk but when trying to boot on bare metal sometimes it had to set up some things on boot or it wouldn’t boot at all but last I checked it boots on bare metal just fine since I pass the whole controller. Windows creates a hell of a lot of partitions… The 2.4GB partition I created though.
Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: ADATA SX900
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 68B86E5F-070E-453A-BC50-B8D3E343B8CF
Device Start End Sectors Size Type
/dev/sda1 2048 923647 921600 450M Windows recovery environment
/dev/sda2 923648 1128447 204800 100M EFI System
/dev/sda3 1128448 1161215 32768 16M Microsoft reserved
/dev/sda4 1161216 991636081 990474866 472.3G Microsoft basic data
/dev/sda5 991637504 993349631 1712128 836M Windows recovery environment
/dev/sda6 993351680 998457343 5105664 2.4G Microsoft basic data
/dev/sda7 998457344 1000214527 1757184 858M Windows recovery environment
I found an old XML, looks like this is how I set up the passthrough back when I used to pass the whole disk.
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='threads'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>