WinServer2016 guest no mouse in VirtManager
by John McInnes
Hi! I recently converted several Windows Server VMs from HyperV to libvirt/KVM. The host is running openSUSE Leap 15.3. I used virt-v2v and I installed virtio drivers on all of them and it all went well - except for one VM. The mouse does not work for this VM in VirtualMachineManager. There is no cursor and no response. There are no issues showing in Windows Device Manager. The mouse shows up as a PS/2 mouse. Interestingly if I RDP into this VM using Microsoft Remote Desktop the mouse works fine. Any ideas?
----
John McInnes
jmcinnes /\T svt.org
1 year, 10 months
detach-interface success but domiflist still saw interface
by Jiatong Shen
Hello Commnunity,
I saw an weird situation on a phytium machine (arm64 v8), after the
following commands, I can still see the interface which should be
successfully detached.
virsh # detach-interface 4a365b06-2597-4c17-8b44-dbb6953f9ced bridge --mac
fa:16:3e:c5:62:40
Interface detached successfully
Future qmp commands shows, that a device hostnet23 exists but seems no
front end device exists.
So what could be the problem? Thank you very much.
/# virsh domiflist --inactive 4a365b06-2597-4c17-8b44-dbb6953f9ced
Interface Type Source Model MAC
------------------------------------------------------------------------
tap1eca5838-d5 bridge qbr1eca5838-d5 virtio fa:16:3e:9b:1c:fd
tap20318b8b-b5 bridge qbr20318b8b-b5 virtio fa:16:3e:e1:bc:58
tap43bab93f-9a bridge qbr43bab93f-9a virtio fa:16:3e:8f:1e:23
tap2b059179-d9 bridge qbr2b059179-d9 virtio fa:16:3e:4e:f9:47
tap1ec7cd98-1d bridge qbr1ec7cd98-1d virtio fa:16:3e:21:5b:e0
tap46c2470d-08 bridge qbr46c2470d-08 virtio fa:16:3e:33:68:19
tap0a402f8f-05 bridge qbr0a402f8f-05 virtio fa:16:3e:89:dd:c4
tap4e737f62-e2 bridge qbr4e737f62-e2 virtio fa:16:3e:1d:2a:1c
tap024ec465-22 bridge qbr024ec465-22 virtio fa:16:3e:16:1c:df
tapd17d320e-a5 bridge qbrd17d320e-a5 virtio fa:16:3e:08:bf:9f
tapcef35fc7-40 bridge qbrcef35fc7-40 virtio fa:16:3e:d6:5b:bf
tap83de3d8e-b5 bridge qbr83de3d8e-b5 virtio fa:16:3e:69:21:90
tap660a3bb9-17 bridge qbr660a3bb9-17 virtio fa:16:3e:b7:33:d3
tap35d08903-93 bridge qbr35d08903-93 virtio fa:16:3e:15:ce:a3
tap8e63ed74-2a bridge qbr8e63ed74-2a virtio fa:16:3e:0a:3f:a8
tapb61b097d-e8 bridge qbrb61b097d-e8 virtio fa:16:3e:f0:f9:da
tap189d75de-ee bridge qbr189d75de-ee virtio fa:16:3e:be:98:9d
tap7108158a-fe bridge qbr7108158a-fe virtio fa:16:3e:a2:8b:e8
tap38015662-f2 bridge qbr38015662-f2 virtio fa:16:3e:d2:45:fe
tapcc37cd83-fc bridge qbrcc37cd83-fc virtio fa:16:3e:64:26:f8
tapaf3ccc2a-0c bridge qbraf3ccc2a-0c virtio fa:16:3e:d2:0a:99
# virsh domiflist 4a365b06-2597-4c17-8b44-dbb6953f9ced
Interface Type Source Model MAC
------------------------------------------------------------------------
tap1eca5838-d5 bridge qbr1eca5838-d5 virtio fa:16:3e:9b:1c:fd
tap20318b8b-b5 bridge qbr20318b8b-b5 virtio fa:16:3e:e1:bc:58
tap43bab93f-9a bridge qbr43bab93f-9a virtio fa:16:3e:8f:1e:23
tap2b059179-d9 bridge qbr2b059179-d9 virtio fa:16:3e:4e:f9:47
tap1ec7cd98-1d bridge qbr1ec7cd98-1d virtio fa:16:3e:21:5b:e0
tap46c2470d-08 bridge qbr46c2470d-08 virtio fa:16:3e:33:68:19
tap0a402f8f-05 bridge qbr0a402f8f-05 virtio fa:16:3e:89:dd:c4
tap4e737f62-e2 bridge qbr4e737f62-e2 virtio fa:16:3e:1d:2a:1c
tap024ec465-22 bridge qbr024ec465-22 virtio fa:16:3e:16:1c:df
tapd17d320e-a5 bridge qbrd17d320e-a5 virtio fa:16:3e:08:bf:9f
tapcef35fc7-40 bridge qbrcef35fc7-40 virtio fa:16:3e:d6:5b:bf
tap7ceb7a77-4d bridge qbr7ceb7a77-4d virtio fa:16:3e:c5:62:40
tap83de3d8e-b5 bridge qbr83de3d8e-b5 virtio fa:16:3e:69:21:90
tap660a3bb9-17 bridge qbr660a3bb9-17 virtio fa:16:3e:b7:33:d3
tap35d08903-93 bridge qbr35d08903-93 virtio fa:16:3e:15:ce:a3
tap8e63ed74-2a bridge qbr8e63ed74-2a virtio fa:16:3e:0a:3f:a8
tapb61b097d-e8 bridge qbrb61b097d-e8 virtio fa:16:3e:f0:f9:da
tap189d75de-ee bridge qbr189d75de-ee virtio fa:16:3e:be:98:9d
tap7108158a-fe bridge qbr7108158a-fe virtio fa:16:3e:a2:8b:e8
tap38015662-f2 bridge qbr38015662-f2 virtio fa:16:3e:d2:45:fe
tapcc37cd83-fc bridge qbrcc37cd83-fc virtio fa:16:3e:64:26:f8
tapaf3ccc2a-0c bridge qbraf3ccc2a-0c virtio fa:16:3e:d2:0a:99
virsh # qemu-monitor-command --hmp 4a365b06-2597-4c17-8b44-dbb6953f9ced
info network
net0: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:9b:1c:fd
\ hostnet0: index=0,type=tap,fd=40
net1: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:e1:bc:58
\ hostnet1: index=0,type=tap,fd=42
net5: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:8f:1e:23
\ hostnet5: index=0,type=tap,fd=52
net9: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:4e:f9:47
\ hostnet9: index=0,type=tap,fd=58
net15: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:21:5b:e0
\ hostnet15: index=0,type=tap,fd=262
net16: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:33:68:19
\ hostnet16: index=0,type=tap,fd=94
net17: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:89:dd:c4
\ hostnet17: index=0,type=tap,fd=108
net18: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:1d:2a:1c
\ hostnet18: index=0,type=tap,fd=218
net19: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:16:1c:df
\ hostnet19: index=0,type=tap,fd=226
net20: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:08:bf:9f
\ hostnet20: index=0,type=tap,fd=234
net21: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d6:5b:bf
\ hostnet21: index=0,type=tap,fd=242
hostnet23: index=0,type=tap,fd=273
net25: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:69:21:90
\ hostnet25: index=0,type=tap,fd=289
net26: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:b7:33:d3
\ hostnet26: index=0,type=tap,fd=44
net27: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:15:ce:a3
\ hostnet27: index=0,type=tap,fd=73
net28: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:0a:3f:a8
\ hostnet28: index=0,type=tap,fd=102
net29: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:f0:f9:da
\ hostnet29: index=0,type=tap,fd=185
net30: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:be:98:9d
\ hostnet30: index=0,type=tap,fd=201
net31: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:a2:8b:e8
\ hostnet31: index=0,type=tap,fd=255
net32: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d2:45:fe
\ hostnet32: index=0,type=tap,fd=279
net33: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:64:26:f8
\ hostnet33: index=0,type=tap,fd=287
net34: index=0,type=nic,model=virtio-net-pci,macaddr=fa:16:3e:d2:0a:99
\ hostnet34: index=0,type=tap,fd=303
--
Best Regards,
Jiatong Shen
2 years
IO while taking a disks-only snapshot
by Or Ozeri
Hi,
Assume I'm running a VM with the qemu driver in libvirt, with multiple disks, with no guest agent.
Now if I take a disks-only snapshot of that active VM.
I see that under the hood, libvirt is issuing a qmp transaction with blockdev-snapshot command per each disk.
I also see that qmp_transaction in qemu is draining all disks IO before performing the transaction (calling bdrv_drain_all).
But once the transaction has started, is it possible that any incoming guest disk IO will be processed before the transaction completes?
Assuming that's not possible, how is this "block disk IO while running the transaction" is enforced? Is it the call to GLOBAL_STATE_CODE() at the beginning of qemu's qmp_transaction(...)?
Thanks,
Or
I
2 years, 1 month
redirect console to file and restore user owner on domain destroy
by Darragh Bailey
Hi,
I'm generating some domain XML to have the serial console output sent to a
file for subsequent debug after the domain is no longer running. I'm
noticing that the file ends up being owned by root with permissions of 600.
I expected that it would need to be owned by root when the VM was running
using the qemu:///system uri for security purposes, however I had hoped
there would be a way to reset the owner and group back to the original
values on destroy.
Is this possible? I had hoped there might be something similar to what is
possible with the permissions element for storage pools.
Started experimenting adding seclabel child elements to the serial element,
but it seems to only affect ownership while the domain is running and when
it is destroyed it still ends up being owned as root.
creating the domain with the following serial/console elements:
<serial type='file'>
<source path='/home/testuser/vagrant-libvirt/logfiles/test.log'>
<seclabel type='dynamic' model='dac' relabel='yes'>
<label>+1002:+1002</label>
</seclabel>
</source>
<target port='0'/>
</serial>
<console type='file'>
<source path='/home/testuser/vagrant-libvirt/logfiles/test.log'/>
<target type='serial' port='0'/>
</console>
I've tried experimenting with a couple of different values but to no
success. It appears to only change the user group the file is set to while
the domain is running, and sets it to root when the VM is destroyed,
instead of returning it to the original user.
Is there any way with libvirt to have the file owned by the user after the
VM is destroyed (doesn't matter if it's owned by root at runtime), when
connecting using qemu:///system?
--
Darragh Bailey
2 years, 1 month
Libvirt slow after a couple of months uptime
by André Malm
Hello,
I have some issues with libvirtd getting slow over time.
After a fresh reboot (or systemctl restart libvirtd) virsh list /
virt-install is fast, as expected, but after a couple of months uptime
they both take a significantly longer time.
Virsh list takes around 3 seconds (from 0.04s on a fresh reboot) and
virt-install takes over a minute (from around a second).
Running strace on virsh list it seems to get stuck in a loop on this:
poll([{fd=5<socket:[173169773]>, events=POLLOUT},
{fd=6<anon_inode:[eventfd]>, events=POLLIN}], 2, -1) = 2 ([{fd=5,
revents=POLLOUT}, {fd=6, revents=POLLIN}])
While restarting libvirtd fixes it a restart takes around 1 minute where
ebtables rules etc are recreated and it does interrupt the service. What
could cause this? How would I troubleshoot this?
I'm running Ubuntu 22.04 / libvirt 8.0.0 with 70 active VM’s on a 16/32
core machine with 256GB of ram, CPU is below 50% usage at all times,
memory below 50% usage and swap 0% usage.
Thanks,
André
2 years, 1 month
CPU frequency in virsh capabilites differs from lscpu
by Mevludin Blazevic
Hi all,
typing virsh capabilities on my one of my server results in the following
output:
<host>
<uuid>5a692c00-7544-11eb-8000-ac1f6b365280</uuid>
<cpu>
<arch>x86_64</arch>
<model>EPYC-Rome</model>
<vendor>AMD</vendor>
<microcode version='137367637'/>
<counter name='tsc' frequency='2799999000'>
lscpu however shows "CPU max MHz" as 2800.0000 on all servers. On my other
machines, virsh capabilites shows the max frequency as follows:
<vendor>AMD</vendor>
<microcode version='137367629'/>
<counter name='tsc' frequency='2800000000'/>
libvirt and qemu version are btw identical. I assume that the CPU clock
speed may differ or is it a libvirt configuration that I need to adjust?
Regards,
Mevludin
2 years, 1 month
domain_qemu_agent_command($domain,$cmd,$timeout,$flags)
by Simon Fairweather
Should there be a way to suppress errors using the flags?
error : qemuDomainAgentAvailable:8411 : Guest agent is not responding:
QEMU guest agent is not connected
Or is there a libvirt function to check connection status or another way?
2 years, 1 month
