- Users - libvirt List Archives

ACLs problem on /dev/kvm
by Sánta, Márton (ext) 22 Feb '23

22 Feb '23

Dear All, I have started to work with libvirt a few weeks ago, but I have some problem with starting a virtual machine. Currently, I am using an embedded arm64 device with a Linux built with Yocto. I managed to install lbvirt 8.1.0 in the image and I have a qemu user and qemu and kvm groups in the system. I am using KVM hypervisor and I did the configuration in the qemu.conf and libvirtd.conf files, enabled all the sockets and services in the system. The xml based definition of the virtual machine is simple, but when I try to start it I get the error message: Failed to start domain 'XYZ' and Unable to set ACLs on /dev/kvm: Invalid argument. I cannot set ACLs on the /dev/kvm (owner is root, group is kvm but I have also tried to set it root:root) with the setfacl command, but I gave rwx access to user, group and others as well so everybody can use the device. I also uncommented the relevant lines in the qemu.conf file (cgroup_controllers = ... and cgroup_device_acl = ...) and I also found that devices controller is already mounted at /sys/fs/cgroup/devices. Can anybody help me with this issue? Did Anybody have similar problem? I can start a virtual machine with qemu-system-aarch64, but I would like to use the libvirt library to manage the machines. Thank you in advance for an early reply. Best regards, Márton Sánta This transmission is intended solely for the addressee and contains confidential information. If you are not the intended recipient, please immediately inform the sender and delete the message and any attachments from your system. Furthermore, please do not copy the message or disclose the contents to anyone unless agreed otherwise. To the extent permitted by law we shall in no way be liable for any damages, whatever their nature, arising out of transmission failures, viruses, external influence, delays and the like.

2 1

there is no PCIe device after command "virsh nodedev-list"
by Martin Bayern 14 Feb '23

14 Feb '23

Hello, I don't know if this is the right email list for this question, let me try. I experienced a problem when I want to assign PCIe VF to my VMs, I can use "lspci" to list the VF PCIe, even PF PCIe, but the command " virsh nodedev-list" doesn't print any PCIe bus device. I tried using "virsh edit --domain " command and added the PCIe bus to the XML file, but when I start the VM, the error message shows an internal error, there is an invalid link to the device. Meanwhile, I use virt-manager to see if I can add a PCIe host device, but the host device shows "no device available". my system is ARM64 based Nvidia platform, I have enabled IOMMU in the kernel. do you know how can I figure out the root cause? is this the ARM64 kernel issue or something else?? I posted this issue also in Nvidia forum: https://forums.developer.nvidia.com/t/nvidia-orin-pcie-device-there-is-no-p… thanks so much for your suggestions. Martin

1 0

Unable to set XATTR trusted.libvirt.security.dac Operation not supported
by Simon Fairweather 07 Feb '23

07 Feb '23

Running with Kernel 6.1.8 QEMU 7.1 libvirt 8.7 setting remeber_owner = 0 resolves the issue but was working ok on kernel 6.0.x. root@computenode:~# cat /etc/libvirt/qemu.conf | grep reme # Whether libvirt should remember and restore the original remember_owner = 0 root@computenode:~# Any known issues for this, is it likely to be QEMU/KVM?

2 4

Installing Kali Linux (kali-linux-2022.4-installer-amd64.iso) using KVM virt-install tool
by Kaushal Shriyan 07 Feb '23

07 Feb '23

Hi, I am trying to install kali-linux-2022.4-installer-amd64.iso ( https://www.kali.org/downloads/) using KVM virt-install tool #virt-install --name=kalilinux --file=/linuxkvmaddgbdisk/kalilinux.img --file-size=50 --nonsparse --vcpu=2 --ram=4096 --network=bridge:br0 --os-type=linux --os-variant=debian9 --graphics none --location=/linuxkvmaddgbdisk/kali-linux-2022.4-installer-amd64.iso --extra-args="console=ttyS0 Starting install... Retrieving file .treeinfo... | 0 B 00:00:00 Retrieving file content... | 0 B 00:00:00 Retrieving file info... | 104 B 00:00:00 Retrieving file info... | 104 B 00:00:00 Retrieving file info... | 104 B 00:00:00 ERROR Could not find an installable distribution at '/linuxkvmaddgbdisk/kali-linux-2022.4-installer-amd64.iso': The URL could not be accessed, maybe you mistyped? The location must be the root directory of an install tree. See virt-install man page for various distro examples. Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start kalilinux otherwise, please restart y #virt-install --name=kalilinux --file=/linuxkvmaddgbdisk/kalilinux.img --file-size=50 --nonsparse --vcpu=2 --ram=4096 --network=bridge:br0 --os-type=linux --os-variant=debian9 --graphics none --cdrom=/linuxkvmaddgbdisk/kali-linux-2022.4-installer-amd64.iso --extra-args="console=ttyS0" ERROR --extra-args only work if specified with --location. See the man page for examples of using --location with CDROM media # osinfo-query os | grep -i debian debian1.1 | Debian GNU/Linux 1.1 | 1.1 | http://debian.org/debian/1.1 debian1.2 | Debian GNU/Linux 1.2 | 1.2 | http://debian.org/debian/1.2 debian1.3 | Debian GNU/Linux 1.3 | 1.3 | http://debian.org/debian/1.3 debian10 | Debian 10 | 10 | http://debian.org/debian/10 debian11 | Debian 11 | 11 | http://debian.org/debian/11 debian2.0 | Debian GNU/Linux 2.0 | 2.0 | http://debian.org/debian/2.0 debian2.1 | Debian GNU/Linux 2.1 | 2.1 | http://debian.org/debian/2.1 debian2.2 | Debian GNU/Linux 2.2 | 2.2 | http://debian.org/debian/2.2 debian3 | Debian GNU/Linux 3.0 | 3.0 | http://debian.org/debian/3 debian3.1 | Debian GNU/Linux 3.1 | 3.1 | http://debian.org/debian/3.1 debian4 | Debian GNU/Linux 4.0 | 4.0 | http://debian.org/debian/4 debian5 | Debian GNU/Linux 5.0 | 5.0 | http://debian.org/debian/5 debian6 | Debian 6.0 | 6.0 | http://debian.org/debian/6 debian7 | Debian 7 | 7 | http://debian.org/debian/7 debian8 | Debian 8 | 8 | http://debian.org/debian/8 debian9 | Debian 9 | 9 | http://debian.org/debian/9 debiantesting | Debian testing | testing | http://debian.org/debian/testing # I did not find kali OS details to provide an option for* --os-variant= * When I ran osinfo-query os | grep kali. It did not return anything. Any help will be highly appreciated and I look forward to hearing from you. Thanks in advance. Best Regards, Kaushal

4 3

Attach a GPS in preboot mode
by lnj.sam＠gmail.com 04 Feb '23

04 Feb '23

Hello everyone and best wishes for 2023 :) I have an old *Garmin Drive Smart 50 GPS* and I want to be able to attach it when it is in preboot mode to a VM hosted by a *Debian 11 host*. From what I understand, the preboot mode allows us to flash a firmware before the GPS actually starts (used among other things when the GPS is soft bricked). When I connect the GPS to the host it gives: |root@host:~# journalctl -kf|| ||# GPS in MTP storage mode (default when reset)|| ||...|| ||janv. 23 23:02:51 host kernel: usb 2-4: New USB device found, idVendor=091e, idProduct=48db, bcdDevice= 0.01|| ||janv. 23 23:02:51 host kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=5|| ||...|| ||# GPS in mass storage mode|| ||...|| ||janv. 23 23:01:29 host kernel: usb 2-4: New USB device found, idVendor=091e, idProduct=28db, bcdDevice= 5.09|| ||janv. 23 23:01:29 host kernel: usb 2-4: New USB device strings: Mfr=0, Product=0, SerialNumber=5|| ||...|| ||# GPS in preboot mode|| ||...|| ||janv. 23 23:09:05 host kernel: usb 2-4: New USB device found, idVendor=091e, idProduct=0003, bcdDevice= 0.01|| ||janv. 23 23:09:05 host kernel: usb 2-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0|| ||janv. 23 23:09:13 host kernel: garmin_gps ttyUSB0: Garmin GPS usb/tty converter now disconnected from ttyUSB0| ... We see that *idVendor*, *idProduct*, *bcdDevice*, *Mfr*, *Product* and *SerialNumber* vary according to the modes.We also see that the GPS is seen as a *ttyUSB0* serial device. I managed to attach the GPS in preboot mode, thanks to a script which waits for the GPS to be detected in this mode (not detailed here so as not to overload, but I can publish it if necessary) and which attaches to a VM in running (*successfully tested on Debian 11 **and**Windows 7 guests*). Here is the code that generates the XML before attaching it : |...|| ||echo "<serial type='dev'> \|| || <source path='"$( \|| || ls -1 /dev/tty* | grep -Ev "tty(|S?[0-9]+)$" \|| || )"'/> \|| || <target type='usb-serial'> \|| || <vendor id='0x"$( \|| || echo 091e \|| || )"'/> \|| || <product id='0x"$( \|| || echo 28db \|| || )"'/> \|| || </target> \|| || </serial>" > serial_device.xml|| ||virsh attach-device vm-bullseye --file serial_device.xml &|| ||...| But once attached, this is what I see in the XML configuration of my VM (from *virt-manager*) : |<serial type="dev">|| || <source path="/dev/ttyUSB1"/>|| || <target type="usb-serial" port="1">|| || <model name="usb-serial"/>|| || </target>|| || <alias name="serial1"/>|| || <address type="usb" bus="0" port="4"/>|| ||</serial>| We see that libvirt has removed the *vendor/product id* from the XML. Also here is what I get from a *Debian 11 guest* : |root@vm-bullseye:~# journalctl -k -f|| ||...|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: new full-speed USB device number 2 using uhci_hcd|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 4.00|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: Product: QEMU USB SERIAL|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: Manufacturer: QEMU|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: SerialNumber: 1-0000:00:05.7-4|| ||janv. 23 21:26:22 vm-bullseye kernel: usbcore: registered new interface driver usbserial_generic|| ||janv. 23 21:26:22 vm-bullseye kernel: usbserial: USB Serial support registered for generic|| ||janv. 23 21:26:22 vm-bullseye kernel: usbcore: registered new interface driver ftdi_sio|| ||janv. 23 21:26:22 vm-bullseye kernel: usbserial: USB Serial support registered for FTDI USB Serial Device|| ||janv. 23 21:26:22 vm-bullseye kernel: ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: Detected FT232BM|| ||janv. 23 21:26:22 vm-bullseye kernel: usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB0|| ||janv. 23 21:26:25 vm-bullseye kernel: usb 3-2: USB disconnect, device number 2|| ||janv. 23 21:26:25 vm-bullseye kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0|| ||janv. 23 21:26:25 vm-bullseye kernel: ftdi_sio 3-2:1.0: device disconnected|| ||...| The guest sees the GPS well but idVendor=*0403*, idProduct=*6001*, bcdDevice=4.00, Mfr=1, Product=2, SerialNumber=4 ... do not correspond to anything, and tools that expect GPS in preboot mode do not see it. My questions : Q1 : Is it possible ? Q2 : Am I doing it the right way ? Q3 : Is there a method to pass such a device directly (pass-through) ? Thank you in advance for the time you are going to devote to me :) With Adelphity, lnj

2 2

WinServer2016 guest no mouse in VirtManager
by John McInnes 03 Feb '23

03 Feb '23

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 1

libvirt error - "cannot set CPU affinity"
by Dipanjan Das 01 Feb '23

01 Feb '23

Hello, I am getting the following error message when trying to run a VM with the emulatorpin cpuset set to a value - "cannot set CPU affinity on process 78: Invalid argument". Note that removing the emulatorpin leads to the VM running successfully. The core that I am setting for the emulatorpin cpuset is present on the system and is not in the isolcpus set of the host. Any suggestions on what could be the problem? Any pointers to how to debug the issue would help greatly too. Some further details if they help - I am using kubevirt (KubeVirt.io <http://kubevirt.io/>) which uses libvirt to manage VM instances in a kubernetes environment. The libvirt version being used is 8.0.0. Thanks, Dipanjan Das

2 3

USB Device Redirection | Change Access For Mount
by Stefanie Leisestreichler 16 Jan '23

16 Jan '23

Hi. I am using kvm/qemu to redirect my mobile phone in a Virtual Machine (via virt-viewer). The mount works automatically but unfortunately the permission to access the files (i.e. photos) is limited to the mounting user only. I want to grant access to other users also. How can I archive this? Thanks, Steffi

1 0

Libvirt dnsmasq oddity
by Charles Curley 15 Jan '23

15 Jan '23

I seem to have hit an oddity in how dnsmasq operates for libvirt. I have two host machines each with several guests. One of those is also the local samba server. Guests on the non-samba server can resolve the samba server's host name correctly, so far without fail. Guests on the samba server sometimes get the correct IP address for the samba server, and other times get an IP address for the samba server of 127.0.1.1. That is the IP address provided in the host's /etc/hosts. Similarly for amanda and hosts. I have a workaround of hard coding the IP address in the fstab entry, but that's tacky. Is there a better way to handle this? One possible way: non-virtual machines use a bind9 server. dnsmasq has an option, --no-hosts, to inhibit reading the hostnames in /etc/hosts. How do I feed that to dnsmasq? Thank you. root@hawk:~# cat /etc/debian_version 11.6 root@hawk:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye root@hawk:~# pre libvirt dnsmasq qemu dnsmasq-base 2.85-1 amd64 gir1.2-libvirt-glib-1.0 3.0.0-1 amd64 ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 all libvirt0 7.0.0-3 amd64 libvirt-clients 7.0.0-3 amd64 libvirt-daemon 7.0.0-3 amd64 libvirt-daemon-config-network 7.0.0-3 all libvirt-daemon-config-nwfilter 7.0.0-3 all libvirt-daemon-driver-lxc 7.0.0-3 amd64 libvirt-daemon-driver-qemu 7.0.0-3 amd64 libvirt-daemon-driver-vbox 7.0.0-3 amd64 libvirt-daemon-driver-xen 7.0.0-3 amd64 libvirt-daemon-system 7.0.0-3 amd64 libvirt-daemon-system-systemd 7.0.0-3 all libvirt-glib-1.0-0 3.0.0-1 amd64 python3-libvirt 7.0.0-2 amd64 qemu 1:5.2+dfsg-11+deb11u2 amd64 qemu-system-common 1:5.2+dfsg-11+deb11u2 amd64 qemu-system-data 1:5.2+dfsg-11+deb11u2 all qemu-system-gui 1:5.2+dfsg-11+deb11u2 amd64 qemu-system-x86 1:5.2+dfsg-11+deb11u2 amd64 qemu-utils 1:5.2+dfsg-11+deb11u2 amd64 root@hawk:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/

1 0

virConnectGetDomainCapabilities
by Simon Fairweather 13 Jan '23

13 Jan '23

Hi Is there a php api version for this? Regards Smon

2 2

question about virtio related options: ats=on and iommu=on
by Yalan Zhang 09 Jan '23

09 Jan '23

Hi, I have a question about the virtio related options, could someone please help to confirm? In my understanding, the ats='on' should depend on the "iommu=on", but I'm not sure about it. Please check the details below. Thank you! Details: 1. set vm with intel iommu device, and enable iommu for virtio filesystem device: # virsh dumpxml rhel --xpath //iommu <iommu model="intel"> <driver intremap="on" caching_mode="on" iotlb="on"/> </iommu> Set iommu="on" ats="on" for virtio filesystem device: # virsh dumpxml rhel --xpath //filesystem <filesystem type="mount" accessmode="passthrough"> <driver type="virtiofs" queue="512" iommu="on" ats="on"/> <binary path="/usr/libexec/virtiofsd" xattr="on"> <cache mode="none"/> </binary> <source dir="/path1"/> <target dir="mount_tag1"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </filesystem> 2. failed to start the vm since "iommu_platform=true is not supported by the device" # virsh start rhel error: Failed to start domain 'rhel' error: internal error: qemu unexpectedly closed the monitor: 2023-01-09T03:48:03.198629Z qemu-kvm: -device {"driver":"vhost-user-fs-pci","iommu_platform":true,"ats":true,"id":"fs0","chardev":"chr-vu-fs0","queue-size":512,"tag":"mount_tag1","bus":"pci.4","addr":"0x0"}: iommu_platform=true is not supported by the device 3. update the xml to be with only ats="on", vm can start successfully, which is not expected. # virsh dumpxml rhel --xpath //filesystem <filesystem type="mount" accessmode="passthrough"> <driver type="virtiofs" queue="512" ats="on"/> <binary path="/usr/libexec/virtiofsd" xattr="on"> <cache mode="none"/> </binary> <source dir="/path1"/> <target dir="mount_tag1"/> <alias name="fs0"/> <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/> </filesystem> the qemu cmd line: -chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-5-rhel/fs0-fs.sock \ -device '{"driver":"vhost-user-fs-pci","ats":true,"id":"fs0","chardev":"chr-vu-fs0","queue-size":512,"tag":"mount_tag1","bus":"pci.4","addr":"0x0"}' Refer to libvirt.org: QEMU's virtio devices have some attributes related to the virtio transport under the driver element: The iommu attribute enables the use of emulated IOMMU by the device. The attribute ats controls the Address Translation Service support for PCIe devices. This is needed to make use of IOTLB support (see IOMMU devices). Possible values are on or off. In my understanding, the ats='on' should depend on the iommu='on', so if the device does not support iommu, it should not support ats, eigher. I'm not sure if the understanding is correct. Could someone please help to confirm it? Thank you! Yalan

2 1

Public IPv6 Bridges
by André Malm 07 Jan '23

07 Jan '23

I'm having trouble getting IPv6 to work for my KVM/qemu guests. I have two bridges setup, one routed (external, non libvirt) bridge for public dedicated ipv4 + ipv6 which works for both protocols. Then I have a libvirt nat bridge (with the routed bridge as parent) with a nated ipv4 (that works) and I also want a public ipv6. I'm able to transmit udp packets out but I never get any response. Looking at tcpdump there are incoming neighbor solicitations that get unanswered and don't get forwarded to the guest. Do I need to set something special up for this to work? Ubuntu 22.04 / Libvirt 8.0.0 The routed bridge (pubBr) has ipv6 2001:x:x:7d8e:: - My nat bridge config below: <network> <name>natbr</name> <bridge name="natbr" /> <forward mode='nat' dev='pubBr'> <nat> <port start='8000' end='30000'/> </nat> </forward> <ip address="10.1.1.1" netmask="255.255.0.0"> <dhcp> <range start='10.1.1.2' end='10.1.1.255'/> </dhcp> </ip> <ip family="ipv6" address="2001:x:x:7d8e::1" prefix="64"> <dhcp> <host name="test" ip="2001:x:x:7d8e:a01:2ff::"/> </dhcp> </ip> </network> Thanks!

1 0

libvirt_connect_get_nic_models
by Simon Fairweather 02 Jan '23

02 Jan '23

Hi Can you confirm that I source get an array of these when running this api call, currently I just get a return of false root@computenode:/mnt/testpool# qemu -nic model=help Supported NIC models: e1000 e1000-82544gc e1000-82545em e1000e i82550 i82551 i82557a i82557b i82557c i82558a i82558b i82559a i82559b i82559c i82559er i82562 i82801 ne2k_pci pcnet rtl8139 tulip virtio-net-pci virtio-net-pci-non-transitional virtio-net-pci-transitional vmxnet3 function domain_get_nic_models($arch = 'x86_64') { $tmp = libvirt_connect_get_nic_models($this->conn, $arch) ; return ($tmp) ? $tmp : $this->_set_last_error(); }

2 2

Snapshots of EFI VMs
by Simon Fairweather 30 Dec '22

30 Dec '22

Is there a timeline to fully support create/remove and revert for these VMs?

1 0

how to add LD_PRELOAD in the xml
by Marc 30 Dec '22

30 Dec '22

How should I add LD_PRELOAD to domain xml. I guess within: <qemu:commandline> <qemu:arg value='env=LD_PRELOAD=/usr/lib64/libtcmalloc.so'/> </qemu:commandline> but this is generating syntax errors.

2 2

Fwd: Need help
by Gk Gk 22 Dec '22

22 Dec '22

FYI.... ---------- Forwarded message --------- From: Gk Gk <ygk.kmr(a)gmail.com> Date: Wed, Dec 21, 2022 at 9:46 PM Subject: Re: Need help To: Daniel P. Berrangé <berrange(a)redhat.com> I have just created a new vm and rechecked the disk stats. This time around too, they seem to be different as shown below: >From libvirt python library: --- disk_name=sda read_req=10501,read_bytes=263819776,write_req=1933,write_bytes=82269184 --- So the write_bytes from above amounted to 78 MB approx. But from within the vm : --- root@sample2:~# iostat -p sda -h Linux 4.15.0-101-generic (sample2) 12/21/2022 _x86_64_ (1 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.9% 0.0% 1.3% 0.4% 0.0% 96.4% Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 40.45 643.6k 21.2M 217.5M 7.2G sda1 40.04 637.6k 21.2M 215.5M 7.2G ---- 7.2 G is far from 78 MB. Am I doing wrong anywhere ? Btw, I did not reboot the new vm this time On Wed, Dec 21, 2022 at 9:30 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote: > On Wed, Dec 21, 2022 at 09:26:14PM +0530, Gk Gk wrote: > > Thanks Daniel for the response. > > > > I am wondering what exactly is the difference in the process for a soft > and > > hard reboot in the context of a kvm guest ? Can you throw some light here > > please ? > > KVM will always do a soft reboot, where QEMU keeps running. > > > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > >

1 0

Fwd: Need help
by Gk Gk 22 Dec '22

22 Dec '22

For larger reach....... ---------- Forwarded message --------- From: Gk Gk <ygk.kmr(a)gmail.com> Date: Thu, Dec 22, 2022 at 8:35 AM Subject: Re: Need help To: Daniel P. Berrangé <berrange(a)redhat.com> Hi Daniel, Did you get a chance to check this out ? Please let me know.... On Wednesday, December 21, 2022, Gk Gk <ygk.kmr(a)gmail.com> wrote: > I have just created a new vm and rechecked the disk stats. This time around too, they seem to be different as shown below: > From libvirt python library: > --- > disk_name=sda read_req=10501,read_bytes=263819776,write_req=1933,write_bytes=82269184 > --- > > So the write_bytes from above amounted to 78 MB approx. > But from within the vm : > --- > root@sample2:~# iostat -p sda -h > Linux 4.15.0-101-generic (sample2) 12/21/2022 _x86_64_ (1 CPU) > > avg-cpu: %user %nice %system %iowait %steal %idle > 1.9% 0.0% 1.3% 0.4% 0.0% 96.4% > > Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn > sda > 40.45 643.6k 21.2M 217.5M 7.2G > sda1 > 40.04 637.6k 21.2M 215.5M 7.2G > ---- > 7.2 G is far from 78 MB. Am I doing wrong anywhere ? Btw, I did not reboot the new vm this time > > > > On Wed, Dec 21, 2022 at 9:30 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote: >> >> On Wed, Dec 21, 2022 at 09:26:14PM +0530, Gk Gk wrote: >> > Thanks Daniel for the response. >> > >> > I am wondering what exactly is the difference in the process for a soft and >> > hard reboot in the context of a kvm guest ? Can you throw some light here >> > please ? >> >> KVM will always do a soft reboot, where QEMU keeps running. >> >> >> With regards, >> Daniel >> -- >> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >> |: https://libvirt.org -o- https://fstop138.berrange.com :| >> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >> >

1 0

Need help
by Gk Gk 21 Dec '22

21 Dec '22

Hi All, I am trying to get guest VM's disk statistics using a libvirt python library as follows: --- raw_xml = domain.XMLDesc(0) for disk in doc.getElementsByTagName('disk'): disk_data = disk.getElementsByTagName('target') --- The above code is yielding the following stats for two disks inside the VM: -- disk_name=sda read_req=34137,read_bytes=445358592,write_req=2405970,write_bytes=24943391744 disk_name=sdb read_req=34357,read_bytes=450754048,write_req=2405984,write_bytes=24943465472 --- The write_bytes divided by 1024 yields 24358853 kB. But when I compare the above statistics from the iostat data shown from inside the VM, I see a stark difference between the two results as shown below: --- root@sample:~# iostat Linux 4.15.0-101-generic (sample) 12/21/2022 _x86_64_ (1 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.27 0.00 0.03 0.02 0.01 99.68 Device tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 0.24 0.04 11.87 400052 121844120 sdb 0.00 0.00 1.19 5269 12223752 ---- Why is there a huge difference in the number of bytes read and written for the two disks as reported by libvirt ? Please explain. Thanks Kumar

2 1

[Question] Which qcow2 options could be inherited to snapshot/blockcopy?
by Meina Li 20 Dec '22

20 Dec '22

Hi, I'm trying to find out which qcow2 options could be inherited to snapshot/blockcopy and then test them. >From https://github.com/qemu/qemu/blob/master/qapi/block-core.json#L4720 we can know all the qcow2 options. As far as I know, size, cluster_size and extended-l2 have already been implemented. So I'm curious that: 1) What are the current status and future plans of other options? Like compat option. 2) Also whether the vol-clone can cover all options? Thank you very much. And please help to correct me if I have something wrong. Best Regards, Meina Li

3 6

Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory
by 陈新隆 20 Dec '22

20 Dec '22

Hi team, i'm trying to hotplug an interface to guest, after execute the command below I got an error : ``` virsh attach-interface --domain 1 --type network --source net1 --model virtio-non-transitional --target /sys/devices/virtual/net/net1/tap603053 --mac ac:de:48:77:a2:32 --config --live error: Failed to attach interface error: Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory ``` According to https://libvirt.org/daemons.html there's two arch of daemon which is "monolithic" and "modular" , so I was wondering if I connect to the monolithic daemon (libvirtd) to attach the interface should works. Then I execute the command below : ``` bash-4.4# virsh -c qemu:///system?socket=/var/run/libvirt/libvirt-sock attach-interface --domain 1 --type network --source net1 --model virtio-non-transitional --target /sys/devices/virtual/net/net1/tap603053 --mac ac:de:48:77:a2:32 --config --live Authorization not available. Check if polkit service is running or see debug message for more information. error: Failed to attach interface error: Failed to connect socket to '/var/run/libvirt/virtnetworkd-sock': No such file or directory ``` Still, I got the same error. My question is : 1. How should I hotplug/unplug an interface without virtnetworkd ? 2. Am I right about the guess of "If I use monolithic daemon then I can hotplug/unplug an interface without virtnetworkd ?

1 0

Testing DKIM handling
by dberrange＠yahoo.com 16 Dec '22

16 Dec '22

Testing DKIM handling RH mail servers

4 9

Global option to configure tb-cache size for tcg feature
by Yatin Karel 16 Dec '22

16 Dec '22

Hi Team, In OpenStack Upstream CI as part of testing we have to create multiple guest vms together on a 8GB VM(no nested-virt support) so we have to use qemu emulation. But with Qemu>=5 'tb-cache' size has increased from 32MiB to 1GiB and due to this we cannot run multiple guest vms together as we have limited resources in CI. We tried to use some swap together but that too didn't helped much as it get's too slow. Thanks Libvirt-8.0.0 now allows to configure tcg feature as below in instance domain.xml:- <features> <tcg> <tb-cache unit='KiB'>32768</tb-cache> </tcg> </features> Is there some global option available in libvirt/qemu which we can use instead of changing each and every xml so we can avoid code changes in nova code[1] for just the CI use case? [1] https://bugs.launchpad.net/nova/+bug/1949606 PS: Please keep me in CC for responses as I am not subscribed to the mailing list. Thanks and Regards Yatin Karel

1 0

qemu flags on libvirt attach-device
by Miguel Ping 13 Dec '22

13 Dec '22

Hello, Is it possible to supply additional flags to libvirt attach-device, similar to libvirt qemu passthrough ( https://libvirt.org/kbase/qemu-passthrough-security.html#xml-document-addit… The passthrough appears to work only for domain creation. I'm particularly interested in the "reconnect-delay" param for nbd based disks. Thanks

1 0

Attach NBD device with qemu flags
by Miguel Ping 12 Dec '22

12 Dec '22

Is there a way to attach an nbd device via eg: virsh attach-device, and provide custom qemu flags? I'm particularly interested in the flag "reconnect-delay". I'm fine with using a language binding (eg: C, Java) for this. Thanks

1 0

Re: Predictable and consistent net interface naming in guests
by Julia Suvorova 12 Dec '22

12 Dec '22

On Thu, Nov 3, 2022 at 9:26 AM Amnon Ilan <ailan(a)redhat.com> wrote: > > > > On Thu, Nov 3, 2022 at 12:13 AM Amnon Ilan <ailan(a)redhat.com> wrote: >> >> >> >> On Wed, Nov 2, 2022 at 6:47 PM Laine Stump <laine(a)redhat.com> wrote: >>> >>> On 11/2/22 11:58 AM, Igor Mammedov wrote: >>> > On Wed, 2 Nov 2022 15:20:39 +0000 >>> > Daniel P. Berrangé <berrange(a)redhat.com> wrote: >>> > >>> >> On Wed, Nov 02, 2022 at 04:08:43PM +0100, Igor Mammedov wrote: >>> >>> On Wed, 2 Nov 2022 10:43:10 -0400 >>> >>> Laine Stump <laine(a)redhat.com> wrote: >>> >>> >>> >>>> On 11/1/22 7:46 AM, Igor Mammedov wrote: >>> >>>>> On Mon, 31 Oct 2022 14:48:54 +0000 >>> >>>>> Daniel P. Berrangé <berrange(a)redhat.com> wrote: >>> >>>>> >>> >>>>>> On Mon, Oct 31, 2022 at 04:32:27PM +0200, Edward Haas wrote: >>> >>>>>>> Hi Igor and Laine, >>> >>>>>>> >>> >>>>>>> I would like to revive a 2 years old discussion [1] about consistent network >>> >>>>>>> interfaces in the guest. >>> >>>>>>> >>> >>>>>>> That discussion mentioned that a guest PCI address may change in two cases: >>> >>>>>>> - The PCI topology changes. >>> >>>>>>> - The machine type changes. >>> >>>>>>> >>> >>>>>>> Usually, the machine type is not expected to change, especially if one >>> >>>>>>> wants to allow migrations between nodes. >>> >>>>>>> I would hope to argue this should not be problematic in practice, because >>> >>>>>>> guest images would be made per a specific machine type. >>> >>>>>>> >>> >>>>>>> Regarding the PCI topology, I am not sure I understand what changes >>> >>>>>>> need to occur to the domxml for a defined guest PCI address to change. >>> >>>>>>> The only think that I can think of is a scenario where hotplug/unplug is >>> >>>>>>> used, >>> >>>>>>> but even then I would expect existing devices to preserve their PCI address >>> >>>>>>> and the plug/unplug device to have a reserved address managed by the one >>> >>>>>>> acting on it (the management system). >>> >>>>>>> >>> >>>>>>> Could you please help clarify in which scenarios the PCI topology can cause >>> >>>>>>> a mess to the naming of interfaces in the guest? >>> >>>>>>> >>> >>>>>>> Are there any plans to add the acpi_index support? >>> >>>>>> >>> >>>>>> This was implemented a year & a half ago >>> >>>>>> >>> >>>>>> https://libvirt.org/formatdomain.html#network-interfaces >>> >>>>>> >>> >>>>>> though due to QEMU limitations this only works for the old >>> >>>>>> i440fx chipset, not Q35 yet. >>> >>>>> >>> >>>>> Q35 should work partially too. In its case acpi-index support >>> >>>>> is limited to hotplug enabled root-ports and PCIe-PCI bridges. >>> >>>>> One also has to enable ACPI PCI hotplug (it's enled by default >>> >>>>> on recent machine types) for it to work (i.e.it's not supported >>> >>>>> in native PCIe hotplug mode). >>> >>>>> >>> >>>>> So if mgmt can put nics on root-ports/bridges, then acpi-index >>> >>>>> should just work on Q35 as well. >>> >>>> >>> >>>> With only a few exceptions (e.g. the first ich9 audio device, which is >>> >>>> placed directly on the root bus at 00:1B.0 because that is where the >>> >>>> ich9 audio device is located on actual Q35 hardware), libvirt will >>> >>>> automatically put all PCI devices (including network interfaces) on a >>> >>>> pcie-root-port. >>> >>>> >>> >>>> After seeing reports that "acpi index doesn't work with Q35 >>> >>>> machinetypes" I just assumed that was correct and didn't try it. But >>> >>>> after seeing the "should work partially" statement above, I tried it >>> >>>> just now and an <interface> of a Q35 guest that had its PCI address >>> >>>> auto-assigned by libvirt (and so was placed on a pcie-root-port)m and >>> >>>> had <acpi index='4'/> was given the name "eno4". So what exactly is it >>> >>>> that *doesn't* work? >>> >>> >>> >>> From QEMU side: >>> >>> acpi-index requires: >>> >>> 1. acpi pci hotplug enabled (which is default on relatively new q35 machine types) >>> >>> 2. hotpluggble pci bus (root-port, various pci bridges) >>> >>> 3. NIC can be cold or hotplugged, guest should pick up acpi-index of the device >>> >>> currently plugged into slot >>> >>> what doesn't work: >>> >>> 1. device attached to host-bridge directly (work in progress) >>> >>> (q35) >>> >>> 2. devices attached to any PXB port and any hierarchy hanging of it (there are not plans to make it work) >>> >>> (q35, pc) >>> >> >>> >> I'd say this is still a relatively important, as the PXBs are needed >>> >> to create a NUMA placement aware topology for guests, and I'd say it >>> >> is undesirable to loose acpi-index if a guest is updated to be NUMA >>> >> aware, or if a guest image can be deployed in either normal or NUMA >>> >> aware setups. >>> > >>> > it's not only Q35 but also PC. >>> > We basically do not generate ACPI hierarchy for PXBs at all, >>> > so neither ACPI hotplug nor depended acpi-index would work. >>> > It's been so for many years and no one have asked to enable >>> > ACPI hotplug on them so far. >>> >>> I'm guessing (based on absolutely 0 information :-)) that there would be >>> more demand for acpi-index (and the resulting predictable interface >>> names) than for acpi hotplug for NUMA-aware setup. >> >> >> My guess is similar, but it is still desirable to have both (i.e. support ACPI-indexing/hotplug with Numa-aware) >> Adding @Peter Xu to check if our setups for SAP require NUMA-aware topology >> >> How big of a project would it be to enable ACPI-indexing/hotplug with PXB? Why would you need to add acpi hotplug on pxb? > Adding +Julia Suvorova and +Tsirkin, Michael to help answer this question > > Thanks, > Amnon > >> >> Since native PCI was improved, we can still compromise on switching to native-PCI-hotplug when PXB is required (and no fixed indexing) Native hotplug works on pxb as is, without disabling acpi hotplug. >> Thanks, >> Amnon >> >> >>> >>> >>> Anyway, it sounds like (*within the confines of how libvirt constructs >>> the PCI topology*) we actually have functional parity of acpi-index >>> between 440fx and Q35. >>>

4 3