- Users - libvirt List Archives

error: internal error: unable to execute QEMU command 'blockdev-mirror': Cannot find device= nor node_name=
by Oliver Dzombic 17 Jan '20

17 Jan '20

Hi, i try to test live-migration using this command: #virsh migrate --copy-storage-all --verbose --live kvm1776 qemu+ssh://nodeb/system Instant error message: error: internal error: unable to execute QEMU command 'blockdev-mirror': Cannot find device=drive-sata0-0-0 nor node_name=drive-sata0-0-0 Its backed via zfs. Source: Virsh command line tool of libvirt 5.10.0 See web site at https://libvirt.org/ Compiled with support for: Hypervisors: QEMU/KVM LXC LibXL OpenVZ VMware PHYP VirtualBox ESX Hyper-V Test Networking: Remote Network Bridging Interface netcf Nwfilter VirtualPort Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM RBD Sheepdog Gluster ZFS Miscellaneous: Daemon Nodedev SELinux Secrets Debug DTrace Readline Target: Virsh command line tool of libvirt 6.0.0 See web site at https://libvirt.org/ Compiled with support for: Hypervisors: QEMU/KVM LXC LibXL OpenVZ VMware VirtualBox ESX Hyper-V Test Networking: Remote Network Bridging Interface netcf Nwfilter VirtualPort Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM RBD Sheepdog Gluster ZFS Miscellaneous: Daemon Nodedev SELinux Secrets Debug DTrace Readline both fedora31. The XML File: <domain type='kvm' id='292'> <name>kvm1776</name> <uuid>a4668f0b-4a71-4956-b74a-a0d3af5fe1f8</uuid> <metadata> <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"> <libosinfo:os id="http://debian.org/debian/10"/> </libosinfo:libosinfo> </metadata> <memory unit='KiB'>8192000</memory> <currentMemory unit='KiB'>8192000</currentMemory> <blkiotune> <device> <path>/dev/kvm-storage/465-9fe4507b-c232-47b3-9b3b-f885359449c6</path> <read_iops_sec>500</read_iops_sec> <write_iops_sec>500</write_iops_sec> <read_bytes_sec>51200000</read_bytes_sec> <write_bytes_sec>51200000</write_bytes_sec> </device> </blkiotune> <vcpu placement='static' current='4'>32</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>IvyBridge-IBRS</model> <vendor>Intel</vendor> <feature policy='require' name='ss'/> <feature policy='require' name='vmx'/> <feature policy='require' name='pcid'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='arat'/> <feature policy='require' name='tsc_adjust'/> <feature policy='require' name='umip'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='stibp'/> <feature policy='require' name='arch-capabilities'/> <feature policy='require' name='ssbd'/> <feature policy='require' name='xsaveopt'/> <feature policy='require' name='pdpe1gb'/> <feature policy='require' name='ibpb'/> <feature policy='require' name='amd-ssbd'/> <feature policy='require' name='skip-l1dfl-vmentry'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <pm> <suspend-to-mem enabled='no'/> <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/kvm-storage/465-9fe4507b-c232-47b3-9b3b-f885359449c6' index='2'/> <backingStore/> <target dev='sda' bus='sata'/> <alias name='sata0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu'/> <target dev='sdb' bus='sata'/> <readonly/> <alias name='sata0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <alias name='ide'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-to-pci-bridge'> <model name='pcie-pci-bridge'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x11'/> <alias name='pci.3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x12'/> <alias name='pci.4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x13'/> <alias name='pci.5'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x14'/> <alias name='pci.6'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x15'/> <alias name='pci.7'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='8' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='8' port='0x16'/> <alias name='pci.8'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </controller> <interface type='bridge'> <mac address='16:c7:25:d4:23:14'/> <source network='Public Network' portid='7291b4be-07a7-49ad-b6ce-b1a0593c96c3' bridge='ovsbr'/> <virtualport type='openvswitch'> <parameters interfaceid='a9ddd087-71ca-456f-bb7b-c2848d11a5a6'/> </virtualport> <target dev='k1776-5nEsy'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/19'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/19'> <source path='/dev/pts/19'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-292-kvm1776/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <alias name='input0'/> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'> <alias name='input1'/> </input> <input type='keyboard' bus='ps2'> <alias name='input2'/> </input> <graphics type='vnc' port='5917' autoport='yes' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <alias name='rng0'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </rng> </devices> <seclabel type='dynamic' model='dac' relabel='yes'> <label>+107:+107</label> <imagelabel>+107:+107</imagelabel> </seclabel> </domain> ---- Any idea ? I could not find anything about this error. Thank you very much ! -- Mit freundlichen Gruessen / Best regards Oliver Dzombic Layer7 Networks mailto:info@layer7.net Anschrift: Layer7 Networks GmbH Zum Sonnenberg 1-3 63571 Gelnhausen HRB 96293 beim Amtsgericht Hanau Geschäftsführung: Oliver Dzombic UST ID: DE259845632

2 1

Reload domain configuration on guest restart
by Gionatan Danti 17 Jan '20

17 Jan '20

Hi all, as you surely know, after changing some domain parameters via libvirt (ie: NIC type), the guest need to be shutdown and restarted. A simple reboot will not be sufficient, as libvirt will not launch a new qemu domain (ie: the same qemu process will be in charge to start the new guest instance). It is possible to configure libvirt to start a new qemu domain on guest reboot? Can the <on_reboot> domain attribute be used for implementing something similar? 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

2 2

libvirt-python: issue on fedora
by Matthias Tafelmeier 16 Jan '20

16 Jan '20

Hello, ran into oddish glitch on fedora 30 cloud image with tooling based on libvirt-python onpython3.7. *qemu-img *is installed though. Could anyone have a look. Build reference, hope it works: https://travis-ci.com/cherusk/godon/builds/144068483?utm_medium=notificatio… Essential stretch: ** ----- Image fedora30 Added Adding a profile named fedora30 with default values + kcli list image +--------------------------------------------+ | Images | +--------------------------------------------+ | /srv/Fedora-Cloud-Base-30-1.2.x86_64.qcow2 | +--------------------------------------------+ + kcli create plan -f /opt/infra/machines.yml micro_fedora Deploying Networks... Network vm_net deployed Deploying Vms... Traceback (most recent call last): File "/usr/bin/kcli", line 11, in <module> load_entry_point('kcli==99.0', 'console_scripts', 'kcli')() File "/usr/lib/python3.7/site-packages/kvirt/cli.py", line 2482, in cli args.func(args) File "/usr/lib/python3.7/site-packages/kvirt/cli.py", line 1071, in create_plan overrides=overrides, wait=wait) File "/usr/lib/python3.7/site-packages/kvirt/config.py", line 1345, in plan plan=plan, basedir=currentplandir, client=vmclient, onfly=onfly, planmode=True) File "/usr/lib/python3.7/site-packages/kvirt/config.py", line 610, in create_vm pcidevices=pcidevices) File "/usr/lib/python3.7/site-packages/kvirt/kvm/__init__.py", line 893, in create storagepool.createXML(volxml, 0) File "/usr/lib64/python3.7/site-packages/libvirt.py", line 3417, in createXML if ret is None:raise libvirtError('virStorageVolCreateXML() failed', pool=self) *libvirt.libvirtError: internal error: creation of non-raw images is not supported without qemu-img * ----- ** -- Regards Matthias Tafelmeier

2 6

[libvirt-users] FYI: intention to remove mail subject prefix & footer text
by Daniel P. Berrangé 15 Jan '20

15 Jan '20

Hi List Subscribers, In recent months we have been seeing an increasing number of bounced deliveries from libvirt mailing lists[1] due to DMARC policies on list subscriber's mail servers. IOW, many subscribers are only receiving a subset of mails sent to the libvirt mailing lists. We believe the root cause of many of the problems is that mailman is modifying the mail subject to add the "[libvirt]" / "[libvirt-users]" prefix, and modifying the mail body to add the footer with links to the listinfo page. These modifications invalidate the DKIM signatures on mails sent to the list by some of our subscribers. This in turn causes DMARC policy rejections by the destination SMTP servers when mailman delivers messages. The solution is to disable any feature in mailman which modifies parts of the mail validated by the DKIM signature. This means removing the subject prefix and the mail body header. Further information on this approach can be seen here: https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html QEMU has made the same change on their mailing list last year: https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg00416.html If you are currently doing mail filtering / sorting based on the subject prefix, you will need to change to use the List-Id header instead. I will wait until the latter part of next week before making this change to allow people time to adapt any filters. Regards, Daniel [1] technically moderators have only been seeing bounces for messages on libvirt-users-list, but that's because we've got mailman configured to send libvir-list bounces to /dev/null. -- |: 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 1

[libvirt-users] error: internal error: Unable to parse 'rbps=max wbps=max riops=100 wiops=max' as an integer
by Oliver Dzombic 13 Jan '20

13 Jan '20

Hi, i am running: libvirt-5.6.0-5.fc31.x86_64 5.4.8-200.fc31.x86_64 Using: <blkiotune> <device> <path>/dev/sda1</path> <read_iops_sec>100</read_iops_sec> <write_iops_sec>100</write_iops_sec> <read_bytes_sec>51200000</read_bytes_sec> <write_bytes_sec>51200000</write_bytes_sec> </device> </blkiotune> and receiving error: internal error: Unable to parse 'rbps=max wbps=max riops=100 wiops=max' as an integer when i try to start it. I found on Redhat Bugzilla a case that claims that its solved by Fixed In Version: libvirt-5.6.0-3.el8 While i am running 5.6.0-5. Maybe its simply because the cgroup v1 is not correctly mounted: # mount | grep cgroup cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) # cat /proc/self/cgroup 0::/user.slice/user-0.slice/session-1.scope But i didnt find anything how to activate that properly. I would be thankful for any suggestions. Thank you! -- Mit freundlichen Gruessen / Best regards Oliver Dzombic Layer7 Networks mailto:info@layer7.net Anschrift: Layer7 Networks GmbH Zum Sonnenberg 1-3 63571 Gelnhausen HRB 96293 beim Amtsgericht Hanau Geschäftsführung: Oliver Dzombic UST ID: DE259845632

2 1

[libvirt-users] Fwd: (no subject)
by Eyüp Hakan Duran 10 Jan '20

10 Jan '20

Thank you so much for your informative response. The man page of virsh did not include "snapshot=no" sub-option under the --diskspec option, but it is very intuitive. Thanks developers for their excellent work! Hakan Peter Krempa <pkrempa(a)redhat.com>, 6 Oca 2020 Pzt, 02:57 tarihinde şunu yazdı: > On Sun, Jan 05, 2020 at 17:21:52 -0600, Eyüp Hakan Duran wrote: > > Dear all, > > Please let me start by indicating that I am not from a technical > > background, so please be gentle and patient with me. > > > > I am trying to get a snapshot from my virtual machines (vm) and the > > following > > command works for all of them bar one: > > > > # virsh snapshot-create-as --quiesce --no-metadata --domain myvm > myvm-state > > --diskspec vda,file=overlay.qcow2 --disk-only --atomic > > You can drop --atomic if you use a qemu released in at least last 5 > years as the snapshot is always atomic if the qemu supports the > 'transaction' command. > > > > > The only exception is this one vm, which has two disks as two separete > > qcow2 files: vda and vdb. Vdb contains my nexcloud data, resides on a > > btrfs subvolume, and a daily snapshot of this subvolume is taken by a > > cronjob > > by the host machine. Therefore, I do not want to include it in the > > snapshot taken by virsh, and therefore I did not include vdb as a > > separate --diskspec item, and used the same command indicated above. > > However, this fails with the following behavior: a state (or rather > > overlay file with a qcow2 extension is created on the host machine's > > directory where the image of vdb exists. My question is the following: > > Is there a way to direct virsh for only taking a snapshot ignoring one > > of the disks? Yes, I can always create that second snapshot/overlay > > Sure. Just use a second --diskspec vdb,snapshot=no > > > image of vdb and delete it later, but it doesn't feel very intuitive, > > and efficient. However, it is quite possible that I may be completely > > overseeing an important aspect of the process, and this may not be > possible > > due to that :). > > One disadvantage of the above operation is that the snapshot of vdb is > not from the same time as vda, but if that doesn't pose a problem in > your scenario it's okay to do it that way. > > > > > Thanks for your inputs in advance. > > > > Hakan Duran > > > _______________________________________________ > > libvirt-users mailing list > > libvirt-users(a)redhat.com > > https://www.redhat.com/mailman/listinfo/libvirt-users > >

2 2

[libvirt-users] Support statement on Nested virtualization
by prabhu padashetty 08 Jan '20

08 Jan '20

Hi Team, I want to confirm if we support Nested Virtualization with AMD based processor as well ?

1 0

[libvirt-users] Locking without virtlockd (nor sanlock)?
by Gionatan Danti 07 Jan '20

07 Jan '20

Hi list, I would like to ask a clarification about how locking works. My test system is CentOS 7.7 with libvirt-4.5.0-23.el7_7.1.x86_64 Is was understanding that, by default, libvirt does not use any locks. From here [1]: "The out of the box configuration, however, currently uses the nop lock manager plugin". As "lock_manager" is commented in my qemu.conf file, I was expecting that no locks were used to protect my virtual disk from guest double-start or misassignement to other vms. However, "cat /proc/locks" shows the following (17532905 being the vdisk inode): [root@localhost tmp]# cat /proc/locks | grep 17532905 42: OFDLCK ADVISORY READ -1 fd:00:17532905 201 201 43: OFDLCK ADVISORY READ -1 fd:00:17532905 100 101 Indeed, try to associate and booting the disk to another machines give me an error (stating that the disk is alredy in use). Enabling the "lockd" plugin and starting the same machine, "cat /proc/locks" looks different: [root@localhost tmp]# cat /proc/locks | grep 17532905 31: POSIX ADVISORY WRITE 19266 fd:00:17532905 0 0 32: OFDLCK ADVISORY READ -1 fd:00:17532905 201 201 33: OFDLCK ADVISORY READ -1 fd:00:17532905 100 101 As you can see, an *additional* write lock was granted. Again, assigning the disk to another vms and booting it up ends with the same error. So, may I ask: - why does libvirtd requests READ locks even commenting the "lock_manager" option? - does it means that I can avoid modifying anything, relying on libvirtd to correctly locks image files? - if so, I should use virtlockd for what use cases? Thanks. [1] https://libvirt.org/locking-lockd.html -- 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

3 9

[libvirt-users] aarch64 vm doesn't boots
by daggs 07 Jan '20

07 Jan '20

Greetings, I'm trying to bring up a alpine rpi aarch64 image within kvm but I'm ended up with a stuck system, here is the xml: <domain type='qemu'> <name>alpine_rpi4_dev_machine</name> <uuid>b1b155fc-cb92-4f22-8904-c934dd24415b</uuid> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <vcpu placement='static'>4</vcpu> <os> <type arch='aarch64' machine='virt'>hvm</type> </os> <features> <gic version='2'/> </features> <cpu mode='custom' match='exact'> <model fallback='allow'>cortex-a53</model> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/dagg/alpine-rpi4.qcow2'/> <target dev='vda' bus='virtio'/> <boot order='2'/> <address type='virtio-mmio'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/home/dagg/alpine-virt-3.11.2-aarch64.iso'/> <target dev='sdb' bus='scsi'/> <readonly/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='scsi' index='0' model='virtio-scsi'> <address type='virtio-mmio'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <model name='i82801b11-bridge'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <model name='pci-bridge'/> <target chassisNr='2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='virtio-mmio'/> </controller> <interface type='network'> <mac address='52:54:00:e0:7a:7b'/> <source network='default'/> <model type='virtio'/> <address type='virtio-mmio'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <console type='pty'> <target type='virtio' port='1'/> </console> </devices> </domain> generated using this cmd: virt-install --cpu cortex-a53 --name alpine_rpi4_dev_machine --cdrom ./alpine-virt-3.11.2-aarch64.iso --disk path=alpine-rpi4.qcow2,size=8 --vcpus 4 --memory 2048 --os-type linux --arch aarch64 I've tried adding a vnc server and vga device but the screen stays black, qxl doesn't work. I'm using ubuntu 16.04 with libvirt 1.3.1, if this is a version issue, I can upgrade to latest version. what I'm I missing? Thanks, Dagg.

2 4

[libvirt-users] (no subject)
by Eyüp Hakan Duran 06 Jan '20

06 Jan '20

Dear all, Please let me start by indicating that I am not from a technical background, so please be gentle and patient with me. I am trying to get a snapshot from my virtual machines (vm) and the following command works for all of them bar one: # virsh snapshot-create-as --quiesce --no-metadata --domain myvm myvm-state --diskspec vda,file=overlay.qcow2 --disk-only --atomic The only exception is this one vm, which has two disks as two separete qcow2 files: vda and vdb. Vdb contains my nexcloud data, resides on a btrfs subvolume, and a daily snapshot of this subvolume is taken by a cronjob by the host machine. Therefore, I do not want to include it in the snapshot taken by virsh, and therefore I did not include vdb as a separate --diskspec item, and used the same command indicated above. However, this fails with the following behavior: a state (or rather overlay file with a qcow2 extension is created on the host machine's directory where the image of vdb exists. My question is the following: Is there a way to direct virsh for only taking a snapshot ignoring one of the disks? Yes, I can always create that second snapshot/overlay image of vdb and delete it later, but it doesn't feel very intuitive, and efficient. However, it is quite possible that I may be completely overseeing an important aspect of the process, and this may not be possible due to that :). Thanks for your inputs in advance. Hakan Duran

2 1