May 2018 - Users - libvirt List Archives

[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang 08 Sep '22

08 Sep '22

Hi guys, when I detach an interface from vm during boot (vm boot not finished), it always fail. I'm not sure if there is an existing bug. I have confirmed with someone that for disk, there is similar behavior, if this is also acceptable? # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:98:c4:a0'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> When I detach after the vm boot, expand the sleep time to 10, it will succeed. # virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh dumpxml rhel7.2 |grep /interface -B9 Domain rhel7.2 destroyed Domain rhel7.2 started Interface detached successfully ------- Best Regards, Yalan Zhang IRC: yalzhang Internal phone: 8389413

3 4

[libvirt-users] Add Virtlyst to the list of libvirt users
by Daniel Nicoletti 24 Sep '20

24 Sep '20

Hi, I've just released v1.0.0 of Virtlyst[1] a web tool to manage VMs using Qt/C++/Cutelyst https://dantti.wordpress.com/2018/04/19/announcing-virtlyst-a-web-interface… Thanks. 1 - https://github.com/cutelyst/Virtlyst -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com

4 5

[libvirt-users] Question about disabling UFO on guest
by Bao Nguyen 05 Aug '20

05 Aug '20

Hello everyone, I would like to ask a question regarding to disable UFO of virtio vNIC in my guest. I have read the document at https://libvirt.org/formatdomain.html *host* The csum, gso, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off host offloading options. By default, the supported offloads are enabled by QEMU. *Since 1.2.9 (QEMU only)* The mrg_rxbuf attribute can be used to control mergeable rx buffers on the host side. Possible values are on (default) and off. *Since 1.2.13 (QEMU only)* *guest* The csum, tso4, tso6, ecn and ufo attributes with possible values on and off can be used to turn off guest offloading options. By default, the supported offloads are enabl ed by QEMU. *Since 1.2.9 (QEMU only)* Then I disabled UFO on my vNIC on guest as the following configuration <devices> <interface type='network'> <source network='default'/> <target dev='vnet1'/> <model type='virtio'/> <driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off' queues='5' rx_queue_size='256' tx_queue_size='256'> *<host gso='off' ufo='off' />* *<guest ufo='off'/>* </driver> </interface> </devices> Then I reboot my node to get the change effect and it works. However, can I disable the UFO without touching the host OS? or it always has to disable on both host and guest like that? Thanks, Brs, Natsu

2 1

[libvirt-users] Libvirt access control drivers
by Anastasiya Ruzhanskaya 22 Nov '18

22 Nov '18

Hello! According to the documentation access control drivers are not in really "good condition". There is a polkit, but it can distinguish users only according the pid. However, I have met some articles about more fine-grained control and about selinux drivers for libvirt? So, what is the status now? Should I implement something by myself if I want access based on login, are their instructions how to write these drivers or there is smth already?

3 18

[libvirt-users] ceph rbd pool and libvirt manageability (virt-install)
by Jelle de Jong 29 Aug '18

29 Aug '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I created a rbd pool and activated it, but I can't seem to create volumes in it with virsh or virt-install? # virsh pool-dumpxml myrbdpool <pool type='rbd'> <name>myrbdpool</name> <uuid>2d786f7a-2df3-4d79-ae60-1535bcf1c6b5</uuid> <capacity unit='bytes'>6997998301184</capacity> <allocation unit='bytes'>10309227031</allocation> <available unit='bytes'>6977204658176</available> <source> <host name='ceph01.powercraft.nl' port='6789'/> <host name='ceph02.powercraft.nl' port='6789'/> <host name='ceph03.powercraft.nl' port='6789'/> <name>libvirt-pool</name> <auth type='ceph' username='libvirt'> <secret uuid='029a334e-ed57-4293-bb99-ffafa8867122'/> </auth> </source> </pool> # virt-install --version 1.0.1 # virsh --version 1.2.9 I ended using virsh edit ceph-test.powercraft.nl and making creating the disk manually. <disk type='network' device='disk'> <auth username='libvirt'> <secret type='ceph' uuid='029a334e-ed57-4293-bb99-ffafa8867122'/> </auth> <source protocol='rbd' name='libvirt-pool/kvm01-storage'> <host name='ceph01.powercraft.nl' port='6789'/> <host name='ceph02.powercraft.nl' port='6789'/> <host name='ceph03.powercraft.nl' port='6789'/> </source> <target dev='vdc' bus='virtio'/> </disk> I use virt-install a lot to define, import and undefine domains, how can I use virt-install to manage my rdb disks? Kind regards, Jelle de Jong -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlV1xlQACgkQ1WclBW9j5HkbPQP+PjNrzvlqysslOp2Yk7wH4Mxy 2sh2dn96G0KOAHEeEn3BN6IWlnD1TADZbHdpTtMwkdv48Xwn0sP1s+3QDM4pb3gP n+z+dVxS8FouDIy/eiso3IBCj3g4TWbEX8ZHqs3jKqe0lZgAXBzB9xYSUowcEBrZ ddkPbr8p8ozWyOG+9V8= =lkK7 -----END PGP SIGNATURE-----

2 3

[libvirt-users] Virtio-net drivers immune to Nethammer?
by procmem 26 Jun '18

26 Jun '18

Hi I'm a privacy distro maintainer investigating the implications of the newly published nethammer attack [0] on KVM guests particularly the virtio-net drivers. The summary of the paper is that rowhammer can be remotely triggered by feeding susceptible* network driver crafted traffic. This attack can do all kinds of nasty things such as modifying SSL certs on the victim system. * Susceptible drivers are those relying on Intel CAT, uncached memory or the clflush instruction. My question is, do virtio-net drivers do any of these things? *** [0] https://arxiv.org/abs/1805.04956

4 7

[libvirt-users] List-Archives ...
by thg 07 Jun '18

07 Jun '18

Hi everybody, actually I wanted to search the list archive, before asking, but unfortunately I don't "get" it: $ gunzip 2018-May.txt.gz gunzip: 2018-May.txt.gz: not in gzip format It seems, that in every archive-file there is always one message in plaintext and then a big binary block. Any hint? Thanks a lot, -- kind regards, thg

3 2

[libvirt-users] Make discard='unmap' the default?
by Ian Pilcher 01 Jun '18

01 Jun '18

Is it possible to make discard='unmap' the default for virtio-scsi disks? (Related, is it possible to make virtio-scsi the default disk type, rather than virtio-blk?) Thanks! -- ======================================================================== Ian Pilcher arequipeno(a)gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ========================================================================

3 6

[libvirt-users] virRandomBits - not very random
by Brian Rak 01 Jun '18

01 Jun '18

I just ran into an issue where I had about 30 guests get duplicate mac addresses assigned. These were scattered across 30 different machines. Some debugging revealed that: 1) All the host machines were restarted within a couple seconds of each other 2) All the host machines had fairly similar libvirtd pids (within ~100 PIDs of each other) 3) Libvirt seeds the RNG using 'time(NULL) ^ getpid()' This perfectly explains why I saw so many duplicate mac addresses. Why is the RNG seed such a predictable value? Surely there has to be a better source of a random seed then the timestamp and the pid? The PID seems to me to be a very bad source of any randomness. I just ran a test across 60 of our hosts. 43 of them shared their PID with at least one other machine.

7 13

[libvirt-users] Two Node Cluster
by Cobin Bluth 01 Jun '18

01 Jun '18

Hello Libvirt Users, I would like to setup a two node bare-metal cluster. I need to guidance on the network configuration. I have attached a small diagram, the same diagram can be seen here: https://i.imgur.com/SOk6a6G.png I would like to configure the following details: - Each node has a DHCP enabled guest network where VMs will run. (eg, *192.168.1.0/24 <http://192.168.1.0/24>* for Host1, and *192.168.2.0/24 <http://192.168.2.0/24>* for Host2) - Any guest in Host1 should be able to ping guests in Host2, and vice versa. - All guests have routes to reach the open internet (so that '*yum update*' will work "out-of-the-box") - Each node will be able to operate fully if the other physical node fails. (no central DHCP server, etc) - I would like to *add more physical nodes later* when I need the resources. This is what I have done so far: - Installed latest Ubuntu 18.04, with latest version of libvirt and supporting software from ubuntu's apt repo. - Each node can reach the other via its own eth0. - Each node has a working vxlan0, which can ping the other via its vxlan0, so it looks like the vxlan config is working. (I used *ip link add vxlan0 type vxlan...*) - Configured route on Host1 like so: *ip route add 192.168.2.0/24 <http://192.168.2.0/24> via 172.20.0.1* - Configured route on Host2 also: *ip route add 192.168.1.0/24 <http://192.168.1.0/24> via 172.20.0.2* - All guests on Host1 (and Host1) can ping eth0 and vxlan0 on Host2, and vice versa, yay. - Guests on Host1 *cannot* ping guests on Host2, I suspect because the the default NAT config of the libvirt network. So, at this point I started to search for tutorials or more information/documentation, but I am a little overwhelmed by the sheer amount of information, as well as a lot of "stale" information on blogs etc. I have learned that I can *virsh net-edit default*, and then change it to an "open" network:* <forward mode='open'/>* After doing this, the guests cannot reach outside their own network, nor reach the internet, so I assume that I would need to add some routes, or something else to get the network functioning like I want it. There is also *<forward mode="route"/>*, but I dont fully understand the scenarios where one would need an *open* or a *route* forward mode. I have also shied away from using openvswitch, and have opted for ifupdown2. (I have taken most of my inspiration from this blog post: https://joejulian.name/post/how-to-configure-linux-vxlans-with-multiple-uni… ) Some questions that I have for the mailing list, any help would be greatly appreciated: - Is my target configuration of a KVM cluster uncommon? Do you see drawbacks of this setup, or does it go against "typical convention"? - Would my scenario be better suited for an "*open*" network or a "*route*" network? - What would be the approach to complete this setup?

3 4

Re: [libvirt-users] VM I/O performance drops dramatically during storage migration with drive-mirror
by Kashyap Chamarthy 30 May '18

30 May '18

Cc the QEMU Block Layer mailing list (qemu-block(a)nongnu.org) who might have more insights here; and wrap long lines. On Mon, May 28, 2018 at 06:07:51PM +0800, Chunguang Li wrote: > Hi, everyone. > > Recently I am doing some tests on the VM storage+memory migration with > KVM/QEMU/libvirt. I use the following migrate command through virsh: > "virsh migrate --live --copy-storage-all --verbose vm1 > qemu+ssh://192.168.1.91/system tcp://192.168.1.91". I have checked the > libvirt debug output, and make sure that the drive-mirror + NBD > migration method is used. > > Inside the VM, I use an I/O benchmark (Iometer) to generate an oltp > workload. I record the I/O performance (IOPS) before/during/after > migration. When the migration begins, the IOPS dropped by 30%-40%. > This is reasonable, because the migration I/O competes with the > workload I/O. However, during almost the last period of migration > (which is 66s in my case), the IOPS dropped dramatically, from about > 170 to less than 10. I also show the figure of this experiment in the > attachment of this email. [The attachment should arrive on the 'libvirt-users' list archives; but it's not there yet -- https://www.redhat.com/archives/libvirt-users/2018-May/thread.html] > I want to figure out what results in this period with very low IOPS. > First, I added some printf()s in the QEMU code, and knew that, this > period occurs just before the memory migration phase. (BTW, the memory > migration is very fast, which is just about 5s.) So I think this > period should be the last phase of the "drive-mirror" process of QEMU. > So then I tried to read the code of "drive-mirror" in QEMU, but failed > to understand it very well. > > Does anybody know what may lead to this period with very low IOPS? > Thank you very much. > > Some details of this experiment: The VM disk image file is 30GB > (format = raw,cache=none,aio=native), and Iometer operates on an 10GB > file inside the VM. The oltp workload consists of 33% writes and 67% > reads (8KB request size, all random). The VM memory size is 4GB, most > of which should be zero pages, so the memory migration is very fast. > > -- > Chunguang Li, Ph.D. Candidate > Wuhan National Laboratory for Optoelectronics (WNLO) > Huazhong University of Science & Technology (HUST) > Wuhan, Hubei Prov., China -- /kashyap

3 4

[libvirt-users] Using libvirt to access Ceph RBDs with Xen
by thg 30 May '18

30 May '18

Hi everybody, my background: I'm doing Xen since 10++ years, many years with DRBD for high availability, since some time I'm using preferable GlusterFS with FUSE as replicated storage, where I place the image-files for the vms. In my current project we started (successfully) with Xen/GlusterFS too, but because the provider, where we placed the servers, uses widely CEPH, we decided to switch too. Unfortunately I'm new to CEPH, but with help of a technician, we have running a 3 node CEPH-cluster now, that seems to work fine. Hardware: - Xeons, 24 Cores, 256 GB RAM, 2x 240 GB system-SSDs RAID1, 4x 1,92 TB data-SSDs (no RAID) Software we are using: - CentOS 7.5.1804 - Kernel: 4.9.86-30.el7 @centos-virt-xen-48 - Xen: 4.8.3-5.el7 @centos-virt-xen-48 - libvirt-xen: 4.1.0-2.xen48.el7 @centos-virt-xen-48 - Ceph: 2:12.2.5-0.el7 @Ceph CEPH itself works, Xen too and even libvirt (I'm quite new in this too, normally I use the XL-tools to manage my VMs) ;-) I can manually map an RBD and start a PV-VM via libvirt, after modifying the XML-config and defined the VM with libvirt. That is what happens: # virsh define xml/testvm3.xml Domain testvm3 defined from xml/testvm3.xml # virsh start --console testvm3 error: Failed to start domain testvm3 error: internal error: libxenlight failed to create new domain 'testvm3' xml/testvm3.xml: -> ... <devices> <disk type='network' device='disk'> <source protocol='rbd' name='devel-pool/testvm3.rbd'> <host name="10.20.30.1" port="6789"/> <host name="10.20.30.2" port="6789"/> <host name="10.20.30.3" port="6789"/> </source> <auth username='libvirt'> <secret type='ceph' uuid='07f3a0fe-9178-xxxxxxxxx'/> </auth> <target dev='xvda' bus='xen'/> </disk> ... Logs: /var/log/libvirt/libxl/libxl-driver.log: -> ... 2018-05-27 11:24:36.666+0000: libxl: libxl_bootloader.c:634:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.14.log 2018-05-27 11:24:36.666+0000: libxl: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [183216] exited with error status 1 2018-05-27 11:24:36.667+0000: libxl: libxl_create.c:1259:domcreate_rebuild_done: cannot (re-)build domain: -3 /var/log/xen/bootloader.14.log: -> Traceback (most recent call last): File "/usr/lib64/xen/bin/pygrub", line 896, in <module> part_offs = get_partition_offsets(file) File "/usr/lib64/xen/bin/pygrub", line 113, in get_partition_offsets image_type = identify_disk_image(file) File "/usr/lib64/xen/bin/pygrub", line 56, in identify_disk_image fd = os.open(file, os.O_RDONLY) OSError: [Errno 2] No such file or directory: 'rbd:devel-pool/testvm3.rbd:id=libvirt:key=AQBThwFbGFRYFxxxxxxxxxxxxxxx==:auth_supported=cephx\\;none:mon_host=10.20.30.1\\:6789\\;10.20.30.2\\:6789\\;10.20.30.3\\:6789' So the Xen-Python-script, that searches for the kernel/bootloader of the VM, does not find the imagefile. But if I grab the above output and use it with qemu, it does find the blockdevice: # qemu-img info "rbd:devel-pool/testvm3.rbd:id=libvirt:key=AQBThwFbGFRYFxxxxxxxxxxxxxxx==:auth_supported=cephx\\;none:mon_host=10.20.30.1\\:6789\\;10.20.30.2\\:6789\\;10.20.30.3\\:6789" -> image: rbd:devel-pool/testvm3.rbd:id=libvirt:key=AQBThwFbGFRYFxxxxxxxxxxxxxxx==:auth_supported=cephx\;none:mon_host=10.20.30.1\:6789\;10.20.30.2\:6789\;10.20.30.3\:6789 file format: raw virtual size: 16G (17179869184 bytes) disk size: unavailable Thus it seems, that CEPH-auth works and the VM-XML-config is interpreted correct by libvirt. But the next step fails, when libvirt should pass the blockdevice to Xen? Anybody out there who uses a similar configuration? Any hints how to debug this? Unfortunately I do not have anymore logs to look at. Thank you very much, -- Kind regards, thg

2 1

[libvirt-users] virsh migration job unexpectedly failed
by cokabug 26 May '18

26 May '18

Hi , when i have run virsh migrate command , the migration progress fiailed at [61 %]. command : virsh migrate --live --undefinesource --p2p --copy-storage-inc --verbose --persistent instance-00001959 qemu+tcp://host292/system result : Migration: [ 61 %]error: operation failed: migration job: unexpectedly failed os/kernel version: centos 6.7 / kernel 2.6.32 qemu-kvm version : 0.12.1.2 libvirt version : 0.10.2-54 the libvirt.log on target host: 2018-05-22 11:45:38.603+0000: 32314: warning : qemuDomainObjTaint:1459 : Domain id=30 name='instance-00001959' uuid=41975d30-2490-473e-be7b-9d2d08bf66d2 is tainted: high-privileges 2018-05-22 11:45:38.883+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:38.902+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:38.903+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:39.090+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:39.090+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:39.091+0000: 32314: warning : qemuDomainObjEnterMonitorInternal:1062 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous 2018-05-22 11:45:41.841+0000: 32310: error : qemuMonitorIO:615 : internal error End of file from monitor the qmeu-kvminstance-00001959.log: 2018-05-22 11:45:38.603+0000: starting up LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/home/ning.zhao USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name instance-00001959 -S -M rhel6.6.0 -cpu Broadwell,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+m$ nitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 41975d30-2490-473e-be7b-9d2d08bf66d2 -smbios type=1,manufacturer=Red Hat Inc.,product=OpenStack Nova,version=2013.1.2-4.el6,serial=fcbe6c27-c9$ d-e811-ac36-a281f9ebc503,uuid=41975d30-2490-473e-be7b-9d2d08bf66d2 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00001959.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -n$ -kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/41975d30-2490-473e-be7b-9d2d08bf66d2/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4$ drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c0:8f:6b,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/41975d30-2490-473e-b$ 7b-9d2d08bf66d2/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 127.0.0.1:2 -k en-us -vga cirrus -incoming tcp: 0.0.0.0:49152 -device virtio-bal$ oon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on Domain id=30 is tainted: high-privileges char device redirected to /dev/pts/2 Receiving block device images qemu: warning: error while loading state for instance 0x0 of device 'block' load of migration failed 2018-05-22 11:45:41.841+0000: shutting down i checked the log and disk file and they have right permissions, has anyone know about this ,i have google many times ,but i cant find the right debug way to resolve it. thanks

2 2

[libvirt-users] Create qcow2 v3 volumes via libvirt
by Gionatan Danti 25 May '18

25 May '18

Hi all, on a fully patched CentOS 7.4 x86-64, I see the following behavior: - when creating a new volumes using vol-create-as, the resulting file is a qcow2 version 2 (compat=0.10) file. Example: [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img Vol zzz.qcow2 created [root@gdanti-lenovo vmimages]# file zzz.qcow2 zzz.qcow2: QEMU QCOW Image (v2), has backing file (path /mnt/vmimages/centos6.img), 8589934592 bytes [root@gdanti-lenovo vmimages]# qemu-img info zzz.qcow2 image: zzz.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 196K cluster_size: 65536 backing file: /mnt/vmimages/centos6.img backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 - when creating a snapshot, the resulting file is a qcow2 version 3 (comapt=1.1) file. Example: [root@gdanti-lenovo vmimages]# virsh snapshot-create-as centos6left --disk-only --no-metadata snap.qcow2 Domain snapshot snap.qcow2 created [root@gdanti-lenovo vmimages]# file centos6left.snap.qcow2 centos6left.snap.qcow2: QEMU QCOW Image (v3), has backing file (path /mnt/vmimages/centos6left.qcow2), 8589934592 bytes [root@gdanti-lenovo vmimages]# qemu-img info centos6left.snap.qcow2 image: centos6left.snap.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 196K cluster_size: 65536 backing file: /mnt/vmimages/centos6left.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false From what I know, this is a deliberate decision: compat=1.1 requires relatively recent qemu version, and creating a new volume play on the "safe side" of compatibility. It is possible to create a new volume using qcow2 version 3 (compat=1.1) format *using libvirt/virsh* (I know I can do that via qemu-img)? Any drawback on using version 3 format? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8

6 17

[libvirt-users] Unable to connect VMs to a bridge over bonded network on Debian 9 (works fine on Centos 7.4)
by Thing 23 May '18

23 May '18

Hi, Sorry of this is the wrong list, trying to find some help. I am trying to set up 2 KVM hosts using Debian 9 (connecting to a 3 node Centos 7.4 gluster cluster) To get the bandwidth I have bonded 2 NICS each end. However while the network works fine for the Debian VM host the VM guests cannot connect/get an IP using DHCP connecting to br0. (Same setup on the Centos end works fine however) On the Debian host if I connect to br1 which is a bridge to a NIC port it works fine. My problem then seems to be at the bonding layer for libvirt/kvm ? Here is my interfaces config, I cannot see the problem. The VM guest is on the gluster cluster and boots fine just no networking. any ideas what I am doing wrong pls? or a better group/list to go ask in? auto eno1 iface eno1 inet manual #iface eno1 inet static bond-master bond0 #address 192.168.1.62 #netmask 255.255.255.0 #gateway 192.168.1.1 #dns-nameservers 192.168.1.241 192.168.1.104 # mtu 9000 auto enp1s0f1 iface enp1s0f1 inet manual bond-master bond0 # mtu 9000 auto bond0 iface bond0 inet static bond-miimon 100 bond-mode 6 bond-updelay 200 bond-xmit_hash_policy layer3+4 bond-lacp-rate 1 # mtu 9000 # address 192.168.1.62 # netmask 255.255.255.0 # gateway 192.168.1.1 # dns-nameservers 192.168.1.241 192.168.1.104 slaves eno1 enp1s0f1 auto br0 iface br0 inet static address 192.168.1.62 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.241 192.168.1.104 bridge_ports bond0 #bridge_ports eno1 enp1s0f1 bridge_stp on bridge_fd 0.0 # mtu 9000 #post-up ifconfig bond0 mtu 9000 #post-up ip link set dev bond0 mtu 9000 #auto bond1 #iface bond1 inet static # address 10.100.200.62 # netmask 255.255.255.0 # bond_slaves enp3s0f1 # bond_primary enp3s0f1 # mtu 9000 auto br1 iface br1 inet static address 10.100.200.62 netmask 255.255.255.0 gateway 10.100.200.1 bridge_ports enp3s0f1 bridge_stp on bridge_fd 0.0 root@kvm02:/etc/network#

1 0

[libvirt-users] Attempting to use Secure Boot for Windows 10
by frizop f 23 May '18

23 May '18

Anybody have a guide on using secure boot? I managed to set */usr/share/edk2/ovmf/OVMF_CODE.secboot.fd* as the* <loader readonly='yes' type='pflash'>*, but when I change this windows only shows me a black screen. I've also tried to fiddle with the following two settings: *<type arch='x86_64' machine='pc-q35-2.10'>* I'm running fedora 27. Any advice on how to implement secure boot for a VM under KVM/Virt-Manager/qemu/etc etc. I found this https://en.opensuse.org/openSUSE:UEFI_Secure_boot_using_qemu-kvm but it doesn't seem to match up with what I'm seeing on a few different aspects, (obviously of which, is I'm not using SuSE) Anyway, any help at all on this would be greatly appreciated. Thanks! -frizop

1 0

[libvirt-users] Performance of guest
by Allence 22 May '18

22 May '18

I recently used Linux in VMware, but I discovered that kvm can replace it, so I created the kvm environment and then started a window on the host system. But when I use it, I have a problem. My guest's performance is not very good. For example, when I use Windows without kvm, the “lol” fps is 160, but my guest is only 135. why? I only have one guest what is the reason? What can we do to promote my performance? There are my some settings for me. timer: hypervclock cpu: 8 socket(intel@ core i7 7700k) memory: 16G GPU: 1060 network: virtio my environment: libvirt: 4.2 qemu: 2.12 windows: windows 7 host: ubuntu server 1604 If you need my detailed settings, please let me know.

2 2

[libvirt-users] Guest's CPU frequency cannot be similar to host system
by Allence 19 May '18

19 May '18

My resource: kernel: 4.16.8 host system: Ubuntu 16.04 Llbvirt : 4.2 Qemu : 2.12 Cpu : intel@core i7 6700 guest system: windows7 professional My problem: In my host, Cpu frequency is 3800~3900 MHz(4 socket and 2 thread) because i turn on “Intel Turbo Boost”. And silent frequency is 3.40 GHz. Then i boot my guest, But in Guest my cpu frequency is 3408 MHz. why it's not 3800 MHz? And here is my guest xml: <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='8' threads='1'/> </cpu>

2 2

[libvirt-users] changing pci addr of SCSI storage controller: Red Hat, Inc Virtio block device (rev 01)
by daggs 13 May '18

13 May '18

Greetings, when execute lspci inside my vm linux guest, I see this: :/# lspci | grep -i scsi 03:00.0 SCSI storage controller: Red Hat, Inc Virtio block device (rev 01) I don't see any such address in my xml file, is it possible to move that controller to another pci addr? Thanks, Dagg.

2 3

[libvirt-users] e1000 network interface takes a long time to set the link ready
by Ihar Hrachyshka 12 May '18

12 May '18

Hi, In kubevirt, we discovered [1] that whenever e1000 is used for vNIC, link on the interface becomes ready several seconds after 'ifup' is executed, which for some buggy images like cirros may slow down boot process for up to 1 minute [2]. If we switch from e1000 to virtio, the link is brought up and ready almost immediately. For the record, I am using the following versions: - L0 kernel: 4.16.5-200.fc27.x86_64 #1 SMP - libvirt: 3.7.0-4.fc27 - guest kernel: 4.4.0-28-generic #47-Ubuntu Is there something specific about e1000 that makes it initialize the link too slowly on libvirt or guest side? [1] https://github.com/kubevirt/kubevirt/issues/936 [2] https://bugs.launchpad.net/cirros/+bug/1768955 Ihar

4 6

Re: [libvirt-users] about python-libvirt
by Andrea Bolognani 10 May '18

10 May '18

[re-adding libvirt-users; please don't take replies off-list] On Thu, 2018-05-10 at 17:32 +0800, lizhuoyao wrote: > Thanks! > > But I'm not clear that what the language binding means? > What the relationship between they? Is that the code from > https://libvirt.org/sources/ can be replaced completely by > the code from https://libvirt.org/sources/python? Language bindings are the means through which libvirt, which is implemented in C, can be used from non-C languages such as Python. It's basically a bunch of glue code that allows Python code to call into C code. In order to use libvirt from Python, you need to have *both* libvirt itself *and* the Python bindings installed on the system: libvirt-python doesn't replace libvirt, and in fact can't work at all unless the C library is available as well. -- Andrea Bolognani / Red Hat / Virtualization

1 0

[libvirt-users] Multi-threaded virsh migrate
by Shawn Q 10 May '18

10 May '18

Hi folk, we are using 10gb NICs with multithreaded compression. We're finding that the standard `virsh migrate` gets at most ~1.2gbps, similar to a single scp session. When we do a multipart upload with multiple scp connections we can squeeze as high as 9.6gbps. Is there was a way to get `virsh migrate` to perform multiple connections as well when transferring? Would be useful to be able to migrate big guests using the full capacity of the 10gb nics. Our example command to migrate: # virsh migrate --compressed --comp-methods mt --comp-mt-level 9 --comp-mt-threads 16 --comp-mt-dthreads 16 --verbose --live --copy-storage-all --undefinesource --unsafe --persistent dev-testvm790.mydomain.net qemu+tcp://myhost-10g.mydomain.net/system

2 2

Re: [libvirt-users] VF MAC not reverted to all zero MAC/domain xml MAC on VM restart
by Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco) 10 May '18

10 May '18

Hi Laine, Thanks for taking the time to respond to my question. I think I have not described my problem clearly. Let me explain my issue below with the information that you had requested. My assumption according to the information you gave me is that the admin MAC and VF MAC are the same in my case. I see a PF (GE0-0) interface but I don’t see a vfnetdev interface as you mentioned in your email. * Given this assumption, when the host is booted, the admin MAC and VF MAC are both 00:00:00:00:00:00. [root@nfvis ~]# ip link show GE0-0 3: GE0-0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 9216<tel:9216> qdisc mq master ovs-system state UP mode DEFAULT qlen 1000<tel:1000> link/ether a0:23:9f:ce:b1:f8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off [root@nfvis ~]# * the VF is assigned to a guest, so the admin MAC is set to the configured value (52:54:00:29:3c:bf) as shown below [root@nfvis ~]# ip link show GE0-0 3: GE0-0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 9216<tel:9216> qdisc mq master ovs-system state UP mode DEFAULT qlen 1000<tel:1000> link/ether a0:23:9f:ce:b1:f8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 52:54:00:29:3c:bf, spoof checking on, link-state auto, trust on vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on [root@nfvis ~]# * Configure bond interface on the guest and added member interface to the bond On doing the above step, bond interface mac (52:54:00:29:3c:be) gets assigned to VF [root@nfvis libvirt]# ip link show GE0-0 3: GE0-0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 9216<tel:9216> qdisc mq master ovs-system state UP mode DEFAULT qlen 1000<tel:1000> link/ether a0:23:9f:ce:b1:f8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 52:54:00:29:3c:be, spoof checking on, link-state auto, trust on vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on [root@nfvis libvirt]# * The next step would be to restart the VM from within the VM console (* we are not doing a shut down and start from the host *). At this stage, the admin MAC is not reverted to the domain xml mac(52:54:00:29:3c:bf) Instead it retains the same bond mac (52:54:00:29:3c:be) which was set before the VM was restarted from the console. [root@nfvis libvirt]# ip link show GE0-0 3: GE0-0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 9216<tel:9216> qdisc mq master ovs-system state UP mode DEFAULT qlen 1000<tel:1000> link/ether a0:23:9f:ce:b1:f8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 52:54:00:29:3c:be, spoof checking on, link-state auto, trust on vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust on So the actual problem we face here, is after the VM is restarted and after the members of bond interface are released, VF mac is not getting reverted back to domain xml mac(52:54:00:29:3c:bf). Instead the VF mac and admin mac are set to the bond mac “52:54:00:29:3c:be” and leading to a duplicate mac issue. My expectation was that after the VM is restarted from the console, libvirt should revert the VF’s MAC to the original MAC, which in our case was the domain xml MAC, which is not happening in my case. Attached is the log file as requested. Interface related contents from domain xml: <interface type='hostdev' managed='yes'> <mac address='52:54:00:29:3c:bf'/> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x0'/> </source> <target dev='vnic1'/> <model type='virtio'/> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </interface> Thanks Thiru. From: sendmail <justsendmailnothingelse(a)gmail.com> On Behalf Of Laine Stump Sent: Wednesday, May 2, 2018 10:01 AM To: Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco) <tsengalv(a)cisco.com> Cc: Chanda Mendon (cmendon) <cmendon(a)cisco.com> Subject: Re: VF MAC not reverted to all zero MAC on VM restart On 04/27/2018 11:08 PM, Thirunavukarasu Sengalvarayan -X (tsengalv - HCL TECHNOLOGIES LIMITED at Cisco) wrote: Hi Laine Stump, We are running linux based VM on KVM based Hypervisor and facing issue with respect to VF MAC. Our Libvirt version: 3.2.0, host driver IGB version 5.2.16 and VF driver IGBVF version 2.3.7.1 Description of problem: When passing a VF to a guest, libvirt sets its MAC according to the domain xml. On shutting down the VM or power off the VM, libvirt attempts to restore its original MAC(all-zero mac). There is no issue with this scenario. When we restart the VM, there is no attempt to restore/revert its original MAC(all zero mac). This problem leads to duplicate MAC issue on the guest (if configured with portchannel). Could you please help us in resolving the issue? Questions like this should be sent to libvirt-users(a)redhat.com<mailto:libvirt-users@redhat.com> rather than to an individual's email address. This makes the likelyhood of getting an answer much higher, and also creates an archive of the problem and eventual solution, which may help others in the future. I'm Cc'ing this response to that list so that any further communication will happen there. Before reading any of the following, it's useful to know this - for SRIOV network devices that *properly* support SRIOV (and I consider those using the igb driver to be in this category) each VF has two MAC addresses that need to be discussed: 1) the VF netdev MAC address (which I will just call the "mac address" - this is the MAC that is known to the VF net driver, and displayed in the output of "ip link show dev $vfnetdev". 2) the MAC address that is stored in the PF driver for each VF, displayed in the "VF" lines immediately following the "ip link" info of the *PF*, and which will be used to initialize the VF's own MAC address when its driver is re-initialized (I will call this the "admin mac") Some VF drivers initialize the mac to 00:00:00:00:00:00 (e.g. the Cisco enic driver) and some initialize it to a random number (e.g. igb and all the other Intel VF net drivers). Likewise, some PF drivers initialize the admin macs to 00:00:00:00:00:00 and some to random numbers (as a matter of fact, this behavior changes between different versions of the same driver in at least one case!). Beyond this, some PF and VF drivers allow setting the mac/admin mac to 00:00:00:00:00:00, and some prohibit one or the other. (in many cases, a driver that itself initializes the mac/admin mac to 00:00:00:00:00:00 also prohibits setting it back to that same value once it has been changed!) When libvirt sets up a VF to be used by a guest (either for vfio device assignment, or for macvtap passthrough), it saves both the mac and the admin mac with the intent of restoring them later. Once these values have been saved, libvirt will set the mac (in the case of macvtap passthrough) or the admin mac (in the case of vfio device assignment), and send the device on to qemu to be used by the guest. After the guest is finished running (or the device is detached), libvirt attempts to restore the settings it had saved at the beginning. Trouble comes up in 2 ways though - 1) once the admin mac has been set for a VF (via the PF), it is no longer possible to directly set the mac (in the VF) (this is done for security reasons, to prevent the guest from changing its mac address), and 2) as said above, many drivers don't allow setting 00:00:00:00:00:00, but in many cases that was the original setting. As of libvirt 3.2.0, libvirt uses the following strategies to work around these problems: a) if setting a non-0 mac (to the VF) fails, then libvirt will try setting the *admin MAC* to that value, then detaching/re-attaching the VF net driver. This will cause the PF to reinitialize the mac in the VF driver. (NB: if we do this, then we don't bother trying to later re-set the admin MAC to its own original value; it's really not important). b) if the failure was in setting the MAC to 00:00:00:00:00:00, then libvirt will set the mac/admin mac to 02:00:00:00:00:00 (which should be a legal value for any driver, but also should not conflict with and "real" mac on the network). Okay, enough background. On to your problem. To make sure I understand your situation correctly: * When the host is booted, the admin MAC is 00:00:00:00:00:00, and VF mac is random (call it rr:rr:rr:rr:rr:rr). * the VF is assigned to a guest (with <interface type='hostdev'> I guess?), so the admin MAC is set to the configured value (let's call it gg:gg:gg:gg:gg:gg) * the guest is shutdown, which causes *both* mac and admin mac to be set to rr:rr:rr:rr:rr:rr * the next time the guest is start *its mac is not changed*? There must be something I'm not getting. Can you maybe perform this test and run "ip link show $PF; ip link show $VF" (substituting the netdev names of the PF and VF for $PF and $VF) after each step to illustrate the problem? Also, it would be helpful to add this to /etc/libvirt/libvirtd.conf: log_filters="1:util.netdev" log_outputs="1:file:/var/log/libvirt/libvirtd-netdev.log<file://var/log/libvirt/libvirtd-netdev.log>" then restart libvirtd (systemctl restart libvirtd.service), and post the contents of libvirtd-netdev.log somewhere and reference it in your next reply. (don't forget to remove those lines and restart libvirtd again after your testing is done!) Finally, you should include the contents of the <interface ...> section of your config in your next response. (BTW, since you're using libvirt-3.2.0, I assume that you are using either RHEL 7.4 or CentOS 7.4. If you are using RHEL, you should open a customer case with Red Hat so that your problem is appropriately prioritized).

3 5

[libvirt-users] Unable to detach disk using 'virsh detach-disk'
by Andre Goree 09 May '18

09 May '18

I'm unable to detach a disk from a Windows guest using the 'virsh detach-disk' command. Even though 'domblklist' shows the disk attached, and on the FIRST iteration, it says the command "completed successfully," 'domblklist will still show the disk attached and subsequent 'detach-disk' commands fail with 'no disk found whose source path or target is ${location}' ~ # virsh domblklist 31907-1063435 Target Source ------------------------------------------------ vda ${concatenated}/31907-1063435/2018-04-28-190529 vdb ${concatenated}/31907-67863/2018-03-21-033216.2018-04-28-190529 ~ # virsh detach-disk --domain 31907-1063435 /var/lib/libvirt/images/instances/31907-67863/2018-03-21-033216.2018-04-28-190529 --persistent error: No disk found whose source path or target is /var/lib/libvirt/images/instances/31907-67863/2018-03-21-033216.2018-04-28-190529 Any ideas as to why this happens? -- Andre Goree -=-=-=-=-=- Email - andre at drenet.net Website - http://blog.drenet.net PGP key - http://www.drenet.net/pubkey.html -=-=-=-=-=-

2 1

[libvirt-users] How to determine if my guest is loaded
by Stallard, Adam 08 May '18

08 May '18

Hi, I am having trouble determining if my VM is up or not. Using virsh leads me to believe that the guest OS is not being loaded: virsh domblkstat guestvm rd_req 0 rd_bytes 0 wr_req 0 wr_bytes 0 flush_operations 0 rd_total_times 0 wr_total_times 0 flush_total_times 0 The VM state is running when outputting list -all. I think the guest OS is just not booted properly. Trying to bring up a console with virsh console guestvm prints: Connected to domain guestvm Escape character is ^] But then I cannot type anything to the screen or see any more output. In my /var/log/libvirt/qemu/domain**/guestvm.log I see no errors. Only the qemu start up command, and a note about redirecting output to console /dev/pts/0. The VM is a custom built image that has a file system mounted on /dev/vg/guestvm. We have a custom kernel at /var/lib/qemu/bzImage. Running a startup command directly with qemu-system-x86_64 allows me to boot the machine properly and bring up a console using netcat. The guest does not use grub. I am not sure if something special is needed in my domain configuration to boot the guest inside the VM. Here is my config: <domain type='qemu'> <name>guestvm</name> <uuid>1878670e-ee57-4059-8d60-243a1559c2d3</uuid> <memory>219200</memory> <currentMemory>219200</currentMemory> <vcpu>2</vcpu> <os> <type arch='i686' machine='pc'>hvm</type> <kernel>/var/lib/qemu/bzImage<kernel/> <boot dev='hd'/> </os> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='block' device='disk'> <source dev='/dev/vg/guestvm'/> <target dev='sda'/> <readonly/> </disk> <interface type='network'> <source network='default'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> </devices> <features> <acpi/> </features> </domain> Any ideas what could be happening? Adam

1 0