hdd kills vm

[daggs]

Greetings Martin,

> Sent: Sunday, October 22, 2023 at 12:37 PM
> From: "Martin Kletzander" <mkletzan at redhat.com>
> To: "daggs" <daggs at gmx.com>
> Cc: libvir-list at redhat.com
> Subject: Re: hdd kills vm
>
> On Fri, Oct 20, 2023 at 02:42:38PM +0200, daggs wrote:
> >Greetings,
> >
> >I have a windows 11 vm running on my Gentoo using libvirt (9.8.0) + qemu (8.1.2), I'm passing almost all available resources to the vm
> >(all 16 cpus, 31 out of 32 GB, nVidia gpu is pt), but the performance is not good, system lags, takes long time to boot.
>
> There are couple of things that stand out to me in your setup and I'll
> assume the host has one NUMA node with 8 cores, each with 2 threads as,
> just like you set it up in the guest XML.
thats correct, see:
$ lscpu | grep -i numa
NUMA node(s):                       1
NUMA node0 CPU(s):                  0-15

however:
$ dmesg | grep -i numa
[    0.003783] No NUMA configuration found

can that be the reason?

>
> * When you give the guest all the CPUs the host has there is nothing
>    left to run the host tasks.  You might think that there "isn't
>    anything running", but there is, if only your init system, the kernel
>    and the QEMU which is emulating the guest.  This is definitely one of
>    the bottlenecks.
I've tried with 12 out of 16, same behavior.

>
> * The pinning of vCPUs to CPUs is half-suspicious.  If you are trying to
>    make vCPU 0 and 1 be threads on the same core and on the host the
>    threads are represented as CPUs 0 and 8, then that's fine.  If that is
>    just copy-pasted from somewhere, then it might not reflect the current
>    situation and can be source of many scheduling issues (even once the
>    above is dealt with).
I found a site that does it for you, if it is wrong, can you point me to a place I can read about it?

>
> * I also seem to recall that Windows had some issues with systems that
>    have too many cores.  I'm not sure whether that was an issue with an
>    edition difference or just with some older versions, or if it just did
>    not show up in the task manager, but there was something that was
>    fixed by using either more sockets or cores in the topology.  This is
>    probably not the issue for you though.
>
> >after trying a few ways to fix it, I've concluded that the issue might be related to the why the hdd is defined at the vm level.
> >here is the xml: https://bpa.st/MYTA
> >I assume that the hdd sits on the sata ctrl causing the issue but I'm not sure what is the proper way to fix it, any ideas?
> >
>
> It looks like your disk is on SATA, but I don't see why that would be an
> issue. Passing the block device to QEMU as VirtIO shouldn't cause that
> much of a difference.  Try measuring the speed of the disk on the host
> and then in the VM maybe.  Is that SSD or NVMe?  I presume that's not
> spinning rust, is it.
as seen, I have 3 drives, 2 cdroms as sata and one hdd pt as virtio, I read somewhere that if the controller of the virtio
device is sata, than it doesn't uses the virtio optimally.
it is a spindle, nvmes are too expensive where I live, frankly, I don't need lightning fast boot, the other BM machines running windows on spindle
run it quite fast and they aren't half as fast as this server

>
> >Thanks,
> >
> >Dagg.
> >
>