The two commands in the OP result in the block device with impossible parameters - its total size is not multiple of its bock size. OVMF ignores such device.
Copying and pasting the commands in OP leads to the Windows installation aborted because system does not meet requirements. So nobody can even reproduce this issue (or, more precisely, nobody really knows what OP did because description is totally insufficient).
@arvidjaar I did wonder about that…
@arvidjaar :
What “OP commands” do you mean specifically?
What am I missing for description to be complete?
@F_style extended_l2=on,cluster_size=128k
@arvidjaar , @malcolmlewis :
Do you mean it should be extended_l2=on,cluster_size=4096 given that I use physical_block_size=4096,logical_block_size=4096 for the disk?
Anyway, I just tried by leaving cluster size 128k and removing the physical/logical block size options, and starting over again.
Still very same result…
I think @arvidjaar may be taking it a bit slightly “personal”, or just him being very intolerant person…
If you just create an image with no options what happens?
I meant exactly what I said.
bor@bor-Latitude-E5450:/tmp$ qemu-img info win11.qcow2
image: win11.qcow2
file format: qcow2
virtual size: 64.8 GiB (69578470400 bytes)
disk size: 388 KiB
cluster_size: 131072
Format specific information:
compat: 1.1
compression type: zlib
lazy refcounts: false
refcount bits: 16
corrupt: false
extended l2: true
bor@bor-Latitude-E5450:/tmp$ bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=2
69578470400/4096
16986931.25
bor@bor-Latitude-E5450:/tmp$
It is basic arithmetic.
Two commands in your original post.
I have no idea. When using these exact commands Windows 11 installation aborted because system did not meet the prerequisites.
Can I ask you how to fix this issue?
I do know arithmetic, I don’t know QEMU arithmetic. Is this enough?
Still marking this as “inappropriate”…
Use device size that is multiple of its block size if you have the reason to use non-default block size.
I just tried disk size 64G instead of 64.8G for qemu-img; removed the “physical_block_size=4096,logical_block_size=4096” part in the qemu disk device.
The only thing I may missed in the OP could be the swtpm stuff to turn on tpm 2.0 for windows vm:
swtpm socket -t --tpm2 --tpmstate dir=virtuals/tpm --ctrl type=unixio,path=virtuals/tpm/swtpm-sock --log level=20 -d
And still OVMF “ignoring the disk”…
It is 4K block size. After reboot.
This can go on and on. Provide the steps to reproduce your issue with “missing” device. Commands that can be copied and pasted to be sure they are exactly the same commands that you are using. Description of selections during installation (there is the whole screen of choices to select virtio driver from). And so on.
@arvidjaar :
TL;DR: Finally solved issue; I think I do owe you apologies…
Complete stuff:
After cooling down a bit, I further checked your qemu-img info example, which was exactly like in my case.
Noticed something: the arithmetic operation 64.8 * 1024 * 1024 * 1024 does not equal 69578470400 bytes, but something some bytes below.
For circumstances, I had to notice this to review what he already said: “its total size is not multiple of its block size; OVMF ignores such device”.
Then I tried with qemu-img creating images with different decimals and doing comparisons. In the end, virtually the only ones correctly matching the arithmetics were disk images with either integer size (xx.0) or at most with exact halves (xx.5). So I guess qemu-img does not get along well with decimal sizes in general…
Then I tried windows installation again; just like I always did in the OP, with the only difference being making with qemu-img disk images sized with, say, exactly 65G, and another with 64.5G.
Result: finally success, windows boot manager finally shows up and continues.
Now, just in case, where did I get those things of “-o extended_l2=on,cluster_size=128k” for qemu-img and “physical_block_size=4096,logical_block_size=4096” for qemu disk?
These are attempts of further optimization of storage performance for windows vm; never though they could be wrong…
Now, just for opened note, I still wonder what could be win11 23h2 ISO’s problem with QEMU -cpu host setting; and also, why changing host to Broadwell CPU made it faster…
Tried asking the libvirt guys, they didn’t know stuff either
Nor why libvirt would choose a Broadwell cpu as better suiting instead of a more recent Skylake…