On Tue, Nov 28, 2023 at 03:53:21PM +0100, Fiona Ebner wrote: > Am 28.11.23 um 15:13 schrieb Daniel P. Berrangé: > > On Tue, Nov 28, 2023 at 02:57:17PM +0100, Fiona Ebner wrote: > >> we received some reports about the new default causing issues for > >> certain guest OSes [0][1]. Namely, for Juniper vSRX, where boot fails > >> and Microsoft Windows, where querying an UUID set via QEMU cmdline > >> -smbios 'type=1,uuid=a4656bd0-a07d-48e0-9dfd-bdc84667a8d0' > >> in Powershell with > >> get-wmiobject win32_computersystemproduct | Select-Object > >> -expandProperty UUID > >> doesn't return any value anymore and can trip up some guest > >> applications. The original report is about Windows 10 and I reproduced > >> this with Windows Server 2019 and the German (but I hope it doesn't > >> matter this time) version of Windows Server 2022. > >> > >> Using machine type 8.0 or the machine option smbios-entry-point-type=32 > >> are workarounds. > >> > >> Since Windows is widely used, that seems a bit unfortunate. Just wanted > >> to ask if you are aware of the issue and if there is something else that > >> can be done other than specifying the more specific machine commandline > >> for those OSes? > > > > I don't recall seeing this issue mentioned before. Could you file a > > bug at https://gitlab.com/qemu-project/qemu > > > > I made one for the Windows issue: > https://gitlab.com/qemu-project/qemu/-/issues/2008 > > It's not clear to me if this is a bug in QEMU or just a bug/limitation > of the guest OS when 64 bit entry is used by SMBIOS. > > I didn't create one for vSRX, because I'm not using it myself and since > it's based on FreeBSD and FreeBSD 13.1 can boot just fine with both 32 > and 64 bit entry, it might be an issue on their side. > > Best Regards, > Fiona
I would be inclined to limit this to when we have too many VCPUs then. Igor WDYT? -- MST
