Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: dibl on 2020/04/30, 16:42:55
-
This morning a full-upgrade brought in the following two changes which may be relevant to my issue::
new kernel 5.6.8-towo-1
upgrade of qemu-system-x86
With the new kernel booted, I have experienced two instances of a Windows 10 VM jumping into an extremely slow mode -- it takes minutes between mouse clicks or movements to see a change on the screen.
After the second time it happened, I rebooted kernel 5.6.7-towo-1, and restarted the VM. It has only been running about 30 minutes now, so I don't know whether I'm going to see the problem with this kernel, or not. If I do, then that will point to the upgraded qemu-system-x86 package as the source of the problem. If I don't see it again, then I will suspect a problem with the new kernel.
I decided to post it in case anyone sees this issue.
-
Normaly i'm running kernel 5.7-rc3, now i have booted with 5.6.8.
I only have one Win 10 VM, but this VM is working like it should.
I'm not using qemu from debian, i build it my own from git.
Can i see your entire qemu command?
-
Hi towo,
I use the Virtual Machine Manager, ver. 2.2.1, and Spice server with QXL video. So no comnand line needed to launch Win 10. It was still running with no problem until I shut it down just now, on 5.6.7. I have not had any trouble with this VM for years, so something in the full-upgrade must have been behind this issue.
Thanks.
EDIT: FYI, when the slowdown happens, I am running an old MS Visual FoxPro application.
-
Even with Virtual Machine Manager there is a corresponding qemu commandline.
ps aux | grep qemu will show it.
-
(1) Still running on 5.6.7, I just now triggered the "semi-freeze" while using Adobe Acrobat to edit a pdf file, so it looks like the problem is not the kernel. It must be the qemu-system-X86 upgrade.
(2) from ps aux:
libvirt+ 1054382 79.4 32.4 13622764 10627784 ? Rl 12:17 11:41 /usr/bin/qemu-system-x86_64 -name guest=win10,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-win10/master-key.aes -machine pc-i440fx-2.12,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu Skylake-Client-IBRS,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 10240 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid e98b6bf6-d366-44c3-a529-790924d99373 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -blockdev {"driver":"file","filename":"/home/don/Win10/win10.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null} -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=libvirt-2-format,id=scsi0-0-0-0,bootindex=1 -blockdev {"driver":"file","filename":"/home/don/Win10/virtio-win-0.1.149.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"} -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,device_id=drive-scsi0-0-0-2,drive=libvirt-1-format,id=scsi0-0-0-2 -netdev tap,fd=35,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e0:b0:51,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
EDIT: I just checked with apt, and now we have these updates for qemu:
qemu qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils
I have another system that I use for experiments -- I'm going to update that one and see if it is stable.
EDIT #2 -- Installed qemu-system-x86 package is ver. 5.0-2. New version is 5.0-3.
-
Looking at that, what VMM is doing, i'm out. Such a branch of useless options.
I'm managing all my vm only with a bash script, for win that is:
#!/bin/bash
USERID=`whoami`
INTERFACE=`sudo /usr/bin/tunctl -b -u $USERID -t tap10`
KVM_GUEST_NAME="Windows 10"
/home/towo/source/qemu/qemu/build/x86_64-softmmu/qemu-system-x86_64 \
-m 6144 \
-name Windows \
-machine type=q35,accel=kvm \
-smp 4,cores=4,sockets=1 \
-cpu host \
-vga qxl \
-spice port=5930,disable-ticketing,streaming-video=filter \
-chardev spicevmc,id=vdagent,debug=0,name=vdagent \
-device virtio-serial \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \
-device intel-hda,id=sound0,msi=on \
-device hda-micro,id=sound0-codec0,bus=sound0.0,cad=0 \
-net nic,macaddr=52:54:00:12:34:56,model=virtio \
-net tap,ifname=$INTERFACE \
-monitor unix:/home/towo/winmonitor,server,nowait \
-drive id=disk,file="/media/daten2/vmware/win10/Windows 10 x64.vmdk",if=none,aio=native,cache=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0 \
-drive id=disk2,file="/media/daten/image/win-daten.img",if=none,aio=native,cache=none -device ahci,id=ahci1 -device ide-hd,drive=disk2,bus=ahci.1 \
-drive file=/home/towo/iso/Win10/19041.207.Vibranium-X64-DE-CLIENTPRO.ISO,format=raw,if=none,id=cd \
-device ide-cd,drive=cd,bus=ide.1 \
sudo ifconfig $INTERFACE down
sudo tunctl -d $INTERFACE
-
That is a nice piece of work! It might be the case, that I must make use of your script for the future.
But, I have no reason to suspect that my branch of useless options is the problem, since it has worked problem-free for years. Something has changed in these new qemu packages.
OK, my experiment on machine B shows the problem still exists after full-upgrade to the new packages. So two different hardware platforms have the same problem, using the new packages. I don't know if it is possible to figure out what the qemu-system-x86 package version was before yesterday, and reinstall that one on my production machine. I see stable uses ver. 3.1+dfsg-8+deb10u5.
-
Before today, it was 4.2-7, which is in testing.
Qemu 5.0 was released yesterday.
-
Yep, thanks. I have reinstalled qemu-system-x86 4-2-7 and qemu-kvm 4-2-7, and launched Win 10. If it is still stable, I am going to pin the necessary qemu packages for awhile, and see what happens with the new packages. Maybe I will find I am not alone. ;D
-
I'm useing qemu 5.0 branch since a long time (from git) and hav not seen such issue here on my systems.
-
I see you are using a .vmdk image. I did not know you could do that. Mine is a .img, made with the VM Manager. I did used to use vmware, and I tried to convert my .vmdk to .img, but that was a failure, so I installed new as .img and built it up from there.
-
@dibl: It's offtopic, so maybe worth another thread.
I have a virtualbox for Windows. but i seems real slow, especially when converting rawfotos (I know, there is darktable). I heard that Qemu/KVM should be faster.
Do you have a how to for installing it?
-
2 subjects:
1) On my "B" platform, running qemu5 and my Win10 VM, I did two things. (1) increased memory for the VM to 16G and (2) downloaded and installed the latest spice-guest-tools package. After restarting the VM, it has been running 4 hours trouble-free, so maybe this is the solution for my case.
2) Hi Lanzi -- obviously, if you see how @towo is running his VM, there are more than one way to use Qemu/KVM. Google found this guide (https://dennisnotes.com/note/20180614-ubuntu-18.04-qemu-setup/). You'll want a bridged network available, so do this (https://wiki.debian.org/BridgeNetworkConnections) first. Get the latest VirIO drivers for windows here (https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers). Once you have Windows running, go here (https://www.spice-space.org/download/binaries/spice-guest-tools/) and download the latest spice-guest-tools package (bottom of the list). Hopefully this is enough to get you started -- it's not a very well documented procedure but you can do it if you're a bit patient.
-
Thanks Dibl. That will help
I will upgrade my computer in the next weeks. Right now, I think I will wait fur a newer siduction iso an start then.
So, back to topic, and excuse again my "hijacking".
-
My Win 10 VM has been running 23 hours on qemu 5 and I can't make it fail, so I must reluctantly mark this thread "solved". I say "reluctantly" because I don't really know what happened that made it go into semi-frozen mode, and I don't know why the two changes I made fixed it. Windows task manager shows the VM only using 2-3G of memory, out of the 16G I gave it. Giving more memory to Windows is like giving a second bottle of vodka to an alcoholic who already has one bottle. Not a very satisfying "solution", but there it is.
-
Could it be because the update to 5.0 was not complete? I've noticed new qemu packages coming slowly in the past few days, so maybe some of the older packages were not working so well with the new ones? Just a wild guess... I tried it in my box (also using Virtual Manager) and I had no problems, though.
-
That is possible finotti. I also saw more qemu packages updated this morning. Maybe I was running a "Frankenqemu". LOL
-
That is possible finotti. I also saw more qemu packages updated this morning. Maybe I was running a "Frankenqemu". LOL
Awesome ! :)
-
I found a more convincing solution to my "almost frozen" Win 10 qemu/KVM issue.
My CPU is an Intel "Kaby Lake" generation, specifically:
$ inxi -C
CPU: Topology: Quad Core model: Intel Core i7-7740X bits: 64 type: MT MCP L2 cache: 8192 KiB
Speed: 4501 MHz min/max: 800/4500 MHz Core speeds (MHz): 1: 4501 2: 4500 3: 4502 4: 4500 5: 4500 6: 4500 7: 4500
8: 4500
I have the CPU set in VMM to "Copy host CPU configuration".
But some googling turned up this post (https://serverfault.com/questions/955439/why-windows-10-virtual-machine-show-high-cpu-load-on-kvm-hyprvisor) with the solution to edit the XML to add
<synic state='on'/>
<stimer state='on'/>
in the "hyperv" paragraph of the XML for the VM. I did that three days ago, gave it only 2 CPUs, and 4 GB of memory, and it has been running problem-free for three days. Apparently something in the qemu 5 update exposed the problem and this change to the XML fixed it.
Now it actually is solved. 8)