- Users - libvirt List Archives

USB-hotplugging fails with "failed to load cgroup BPF prog: Operation not permitted" on cgroups v2
by Pol Van Aubel 20 Jan '20

20 Jan '20

Hi all, I've disabled cgroups v1 on my system with the kernel boot option "systemd.unified_cgroup_hierarchy=1". Since doing so, USB hotplugging fails to work, seemingly due to a permissions problem with BPF. Please note that the technique I'm going to describe worked just fine for hotplugging USB devices to running domains until this change. Attaching / detaching USB devices when the domain is down still works as expected. I get the same error when attaching a device in virt-manager, as I do when running the following command: sudo virsh attach-device wenger /dev/stdin --persistent <<END <hostdev mode='subsystem' type='usb' managed='yes'> <source startupPolicy='optional'> <vendor id='0x046d' /> <product id='0xc215' /> </source> </hostdev> END This returns error: Failed to attach device from /dev/stdin error: failed to load cgroup BPF prog: Operation not permitted virt-manager returns basically the same error, but for completeness' sake, here it is: failed to load cgroup BPF prog: Operation not permitted Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/addhardware.py", line 1327, in _add_device self.vm.attach_device(dev) File "/usr/share/virt-manager/virtManager/object/domain.py", line 920, in attach_device self._backend.attachDevice(devxml) File "/usr/lib/python3.8/site-packages/libvirt.py", line 590, in attachDevice if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self) libvirt.libvirtError: failed to load cgroup BPF prog: Operation not permitted Now, libvirtd is running as root, so I don't understand why any operation on BPF programs is not permitted. I've dug into libvirt's code a bit to see what is throwing this error and it boils down to <https://github.com/libvirt/libvirt/blob/7d608469621a3fda72dff2a89308e68cc9f…> and <https://github.com/libvirt/libvirt/blob/02bf7cc68bfc76242f02d23e73cad36618f…> but I have no clue what that syscall is doing, so that's where my debugging capability basically ends. Maybe this is something as simple as setting the right ACL somewhere. I haven't touched /etc/libvirt/qemu.conf except for setting nvram. There *is* something about cgroup_device_acl there but afaict that's for cgroups v1, when there was still a device cgroup controller. Any help would be greatly appreciated. Domain log files: Upon execution of the above commands, nothing gets added to the domain log in /var/log/qemu/wenger.log, so I've decided they're likely irrelevant to the issue. Please ask for any additional info required. System information: Arch Linux, (normal) kernel 5.4.11 libvirt 5.10.0 qemu 4.2.0, using KVM. Host system is x86_64 on an intel 5820k. Guest system is probably irrelevant, but is Windows 10 on the same. Possibly relevant kernel build options: $ zgrep BPF /proc/config.gz [22:55:52]: zgrep BPF /proc/config.gz CONFIG_CGROUP_BPF=y CONFIG_BPF=y CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT_ALWAYS_ON=y CONFIG_IPV6_SEG6_BPF=y CONFIG_NETFILTER_XT_MATCH_BPF=m # CONFIG_BPFILTER is not set CONFIG_NET_CLS_BPF=m CONFIG_NET_ACT_BPF=m CONFIG_BPF_JIT=y CONFIG_BPF_STREAM_PARSER=y CONFIG_LWTUNNEL_BPF=y CONFIG_HAVE_EBPF_JIT=y CONFIG_BPF_EVENTS=y # CONFIG_BPF_KPROBE_OVERRIDE is not set # CONFIG_TEST_BPF is not set Regards, Pol Van Aubel

2 1

Prevent virsh live migration from copy zero -- increment copy on live migration possible ?
by Oliver Dzombic 18 Jan '20

18 Jan '20

Hi, i am doing a live migration like this: [root@nodeA ~]#virsh migrate --copy-storage-all --verbose --live kvm1776 qemu+ssh://nodeb/system which works fine with libvirt version 6. The zfs backed hdd is 100G, while its thin-provisioned. The real data on it is 1G. So even its 1G of data, virsh copies a lot of zero's as it seems. There is a lot of HDD IO and network activity, but in fact the size at the target volume does not grow ( since there are no more data ). After it successfully finished the copy, i tried what will happen with the --copy-storage-inc parameter: [root@nodeB ~]# virsh migrate --copy-storage-inc --verbose --live kvm1776 qemu+ssh://nodea/system But that didnt change anything. Even both volumes are identical now, again the whole copy of all ( non existing ) 100GB. Is there any way to make libvirt just copy real data and not Zero's that actually do not exist and causing network and HDD IO traffic ? 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

1 0

Bridge-less VM
by Rob Roschewsk 18 Jan '20

18 Jan '20

I'm trying to create a free standing VM that doesn't connect to a bridge. This is supposedly do able according to the WIKI: https://libvirt.org/formatdomain.html#elementsNICSEthernet But with a config similar to: <interface type='ethernet'> <target dev='mytap1' managed='no'/> <model type='virtio'/> </interface> When starting the domain I get the error: error: internal error: process exited while connecting to monitor: 2020-01-16T18:08:04.788860Z qemu-system-x86_64: -netdev tap,id=hostnet0,vhost=on,vhostfd=26: could not open /dev/net/tun: Operation not permitted Checked permissions on /dev/net/tunand it's 666 If I just configure it as a "bridge" connection the domain starts. Then I can use brctl to remove it from the bridge to get what I want. That just proves it possible but with extra steps (Shout out to Rick and Morty) Thoughts?? Running Ubuntu 16.04.1 Kernel 4.15.0-74 libvirt 1.3.1-1ubuntu10.27 qemu 1:2.5+dfsg-5ubuntu10.41 Thanks, --> Rob

2 1

Volume file permissions and huge volume downloads
by R. Diez 18 Jan '20

18 Jan '20

Hi all: I am using the libvirt version that comes with Ubuntu 18.04.3 LTS. I want to backup a virtual machine in a foolproof way: - Gracefully shutdown the VM. - Backup the disk image. - Restart the VM. I wrote the following script to do that: https://github.com/rdiez/Tools/blob/master/VirtualMachineManager/BackupVm.sh Writing that script was difficult enough because of the virsh limitations (in my opinion) described in the comments. But at least it works. The main problem is that libvirt sets the ownership and permissions of volume files in such a way that a standard user cannot access them, even if it is member of the 'libvirt' group. While the VM is running, volume file permissions are like this: -rw-r----- 1 libvirt-qemu kvm [...] /var/lib/libvirt/images/YourVmDisk.qcow2 When the VM is shutoff: -rw-r----- 1 root root [...] /var/lib/libvirt/images/YourVmDisk.qcow2 The trouble is, I want to access that .qcow2 file when the VM is shutoff. I would really like not to run my script as root. I could not find a way to specify the permissions for the .qcow2 files, so I tried editing the group ownership for the whole pool: virsh pool-edit default <target> <path>/var/lib/libvirt/images</path> <permissions> <mode>0711</mode> <owner>0</owner> <group>131</group> </permissions> </target> Setting <group> to "libvirt" did not work (XML validation error), so I tried the numeric ID of that group (131). That did not work. When I restart libvirt with "service libvirtd restart", my changes to the pool XML file disappear (!). Later on, I found out that you can download a volume like this: virsh vol-download --pool default YourVmDisk.qcow2 YourVmDisk.qcow2 The trouble is that I created the virtual disk with a maximum size of 120 GB. I copied it around a few times, so I think it has lost any "sparseness" inside. Command "virsh vol-download" takes ages and downloads all those 120 GB. My script uses "qemu-img convert", which discards all unused space and writes just 17 GB of data, and that is without turning compression on. The whole backup takes seconds instead of minutes. Can somebody help me with these issues? Thanks in advance, rdiez

2 1

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 17 Jan '20

17 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é 16 Jan '20

16 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 08 Jan '20

08 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

[libvirt-users] [Xen] + [Libvirt] + [TPM]: can it work?
by Arthur Borsboom 03 Jan '20

03 Jan '20

I am trying to get TPM 2.0 pass through to work with Xen and libvirt, but I can't get it to work. According to the following sites both Xen and libirt have TPM 2.0 support. https://wiki.xen.org/wiki/Virtual_Trusted_Platform_Module_(vTPM) https://libvirt.org/formatdomain.html#elementsTpm However, when I add a TPM device to a VM (by virt-manager), the VM guest XML does contain the TPM configuration, but the VM guest (linux) does not show any TPM device. Also, when looking in /var/log/libvirt/libxl/vmguest.log there is no mention of tpm in the (converted libvirt XML to libxl) vm structure. Is this because libvirt only supports TPM with QEMU? If so, are there any development plans for TPM support with XEN? Is there a workaround for the time being? -- Arthur Borsboom Mob: +31629089953 Email: arthurborsboom(a)gmail.com [image: View Arthur's LinkedIn profile] <http://uk.linkedin.com/in/arthurborsboom>

2 1

[libvirt-users] Passing multiple addresses with masks to nwfilter
by Brooks Swinnerton 02 Jan '20

02 Jan '20

Hello, I have a nwfilter that I'm using to ensure that libvirt domains can't spoof IPv6 traffic. It looks like this: <filter name='no-ipv6-spoofing' chain='ipv6-ip' priority='-710'> <rule action='return' direction='out' priority='500'> <ipv6 srcipaddr='$IPV6' srcipmask='$IPV6MASK'/> </rule> <rule action='drop' direction='out' priority='1000'/> </filter> The goal is to allow any traffic coming from the entire prefix (e.g. 2001:db8::/32). This theoretically would work fine when passing in the variables from the domain definition like so: <filterref filter='no-ipv6-spoofing'> <parameter name='IPV6' value='2001:db8:1:6:dc:d2ff:fef2:2181'/> <parameter name='IPV6_MASK' value='32'/> </filterref> But the problem comes when wanting to allow multiple prefixes (and thus multiple $IPV6 and $IPV6_MASK variables). If there is more than one definition of $IPV6, how could I associate it with a corresponding $IPV6_MASK? Ideally I would be able to pass an address in CIDR notation directly to srcipaddr, but I don't believe that's an option. Any guidance would be appreciated. The ultimate goal is to automate this process, so having something like $IPV6_1 and $IPV6_1 would be less than ideal.

1 2

[libvirt-users] (no subject)
by Mauricio Tavares 24 Dec '19

24 Dec '19

When I use kvm+libvirt as my hypervisor at home, I usually pass logical volumes as the guests' drives (I probably can do better but the disk here is just a garden-variety SSD, not NVMe). <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source file='/dev/vmhost_vg0/desktop'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> That works fine as local drives, but what about if I want to use the network storage (can provide nfs and iscsi)? Should I: 1. Create one iscsi target for each guest? Reasoning here is that some OS can boot off iscsi. 2. Create a local lv with the minimum required disk space to boot, and then network mount the rest be it as nfs or iscsi? 3. Create a large iscsi target, do not format it, but instead configure it as a lvm, handing out logical volumes as before? So the vm guest won't know any better. I am leaning towards door #3, but I am open for suggestions.

2 1

[libvirt-users] Add support for vhost-user-scsi-pci/vhost-user-blk-pci
by Li Feng 23 Dec '19

23 Dec '19

Hi Guys, And I want to add the vhost-user-scsi-pci/vhost-user-blk-pci support for libvirt. The usage in qemu like this: Vhost-SCSI -chardev socket,id=char0,path=/var/tmp/vhost.0 -device vhost-user-scsi-pci,id=scsi0,chardev=char0 Vhost-BLK -chardev socket,id=char1,path=/var/tmp/vhost.1 -device vhost-user-blk-pci,id=blk0,chardev=char1 What type should I add for libvirt. Type1: <hostdev mode='subsystem' type='vhost-user'> <source protocol='vhost-user-scsi' path='/tmp/vhost-scsi.sock'></source> <alias name="vhost-user-scsi-disk1"/> </hostdev> Type2: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source protocol='vhost-user' path='/tmp/vhost-scsi.sock'> </source> <target dev='sdb' bus='vhost-user-scsi'/> <boot order='3'/> <alias name='scsi0-0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source protocol='vhost-user' path='/tmp/vhost-blk.sock'> </source> <target dev='vda' bus='vhost-user-blk'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> Could anyone give some suggestions? Thanks, Feng Li -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.

2 5

[libvirt-users] CfP VHPC20: HPC Containers-Kubernetes
by VHPC 20 20 Dec '19

20 Dec '19

==================================================================== CALL FOR PAPERSa 15th Workshop on Virtualization in High-Performance Cloud Computing (VHPC 20) held in conjunction with the International Supercomputing Conference - High Performance, June 21-25, 2020, Frankfurt, Germany. (Springer LNCS Proceedings) ==================================================================== Date: June 25, 2020 Workshop URL: vhpc[dot]org Abstract registration Deadline: Jan 31st, 2020 Paper Submission Deadline: Apr 05th, 2020 Springer LNCS Call for Papers Containers and virtualization technologies constitute key enabling factors for flexible resource management in modern data centers, and particularly in cloud environments. Cloud providers need to manage complex infrastructures in a seamless fashion to support the highly dynamic and heterogeneous workloads and hosted applications customers deploy. Similarly, HPC environments have been increasingly adopting techniques that enable flexible management of vast computing and networking resources, close to marginal provisioning cost, which is unprecedented in the history of scientific and commercial computing. Most recently, Function as a Service (Faas) and Serverless computing, utilizing lightweight VMs-containers widens the spectrum of applications that can be deployed in a cloud environment, especially in an HPC context. Here, HPC-provided services can be become accessible to distributed workloads outside of large cluster environments. Various virtualization-containerization technologies contribute to the overall picture in different ways: machine virtualization, with its capability to enable consolidation of multiple underutilized servers with heterogeneous software and operating systems (OSes), and its capability to live-migrate a fully operating virtual machine (VM) with a very short downtime, enables novel and dynamic ways to manage physical servers; OS-level virtualization (i.e., containerization), with its capability to isolate multiple user-space environments and to allow for their coexistence within the same OS kernel, promises to provide many of the advantages of machine virtualization with high levels of responsiveness and performance; lastly, unikernels provide for many virtualization benefits with a minimized OS/library surface. I/O Virtualization in turn allows physical network interfaces to take traffic from multiple VMs or containers; network virtualization, with its capability to create logical network overlays that are independent of the underlying physical topology is furthermore enabling virtualization of HPC infrastructures. Publication Accepted papers will be published in a Springer LNCS proceedings volume. Topics of Interest The VHPC program committee solicits original, high-quality submissions related to virtualization across the entire software stack with a special focus on the intersection of HPC, containers-virtualization and the cloud. Major Topics: - HPC workload orchestration (Kubernetes) - Kubernetes HPC batch - HPC Container Environments Landscape - HW Heterogeneity - Container ecosystem (Docker alternatives) - Networking - Lightweight Virtualization - Unikernels / LibOS - State-of-the-art processor virtualization (RISC-V, EPI) - Containerizing HPC Stacks/Apps/Codes: Climate model containers each major topic encompassing design/architecture, management, performance management, modeling and configuration/tooling. Specifically, we invite papers that deal with the following topics: - HPC orchestration (Kubernetes) - Virtualizing Kubernetes for HPC - Deployment paradigms - Multitenancy - Serverless - Declerative data center integration - Network provisioning - Storage - OCI i.a. images - Isolation/security - HW Accelerators, including GPUs, FPGAs, AI, and others - State-of-practice/art, including transition to cloud - Frameworks, system software - Programming models, runtime systems, and APIs to facilitate cloud adoption - Edge use-cases - Application adaptation, success stories - Kubernetes Batch - Scheduling, job management - Execution paradigm - workflow - Data management - Deployment paradigm - Multi-cluster/scalability - Performance improvement - Workflow / execution paradigm - Podman: end-to-end Docker alternative container environment & use-cases - Creating, Running containers as non-root (rootless) - Running rootless containers with MPI - Container live migration - Running containers in restricted environments without setuid - Networking - Software defined networks and network virtualization - New virtualization NICs/Nitro alike ASICs for the data center? - Kubernetes SDN policy (Calico i.a.) - Kubernetes network provisioning (Flannel i.a.) - Lightweight Virtualization - Micro VMMs (Rust-VMM, Firecracker, solo5) - Xen - Nitro hypervisor (KVM) - RVirt - Cloud Hypervisor - Unikernels / LibOS - HPC Storage in Virtualization - HPC container storage - Cloud-native storage - Hypervisors in storage virtualization - Processor Virtualization - RISC-V hypervisor extensions - RISC-V Hypervisor ports - EPI - Composable HPC microservices - Containerizing Scientific Codes - Building - Deploying - Securing - Storage - Monitoring - Use case for containerizing HPC codes: Climate model containers for portability, reproducibility, traceability, immutability, provenance, data & software preservation The Workshop on Virtualization in High-Performance Cloud Computing (VHPC) aims to bring together researchers and industrial practitioners facing the challenges posed by virtualization in order to foster discussion, collaboration, mutual exchange of knowledge and experience, enabling research to ultimately provide novel solutions for virtualized computing systems of tomorrow. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections, plus lightning talks that are limited to 5 minutes. Presentations may be accompanied by interactive demonstrations. Important Dates Jan 31st, 2020 - Abstract Apr 5th, 2020 - Paper submission deadline (Springer LNCS) Apr 26th, 2020 - Acceptance notification June 25th, 2020 - Workshop Day July 10th, 2020 - Camera-ready version due Chair Michael Alexander (chair), BOKU, Vienna, Austria Anastassios Nanos (co-chair), Sunlight.io, UK Program committee Stergios Anastasiadis, University of Ioannina, Greece Paolo Bonzini, Redhat, Italy Jakob Blomer, CERN, Europe Eduardo César, Universidad Autonoma de Barcelona, Spain Taylor Childers, Argonne National Laboratory, USA Stephen Crago, USC ISI, USA Tommaso Cucinotta, St. Anna School of Advanced Studies, Italy François Diakhaté CEA DAM Ile de France, France Kyle Hale, Northwestern University, USA Brian Kocoloski, Washington University, USA John Lange, University of Pittsburgh, USA Giuseppe Lettieri, University of Pisa, Italy Klaus Ma, Huawei, China Alberto Madonna, Swiss National Supercomputing Center, Switzerland Nikos Parlavantzas, IRISA, France Anup Patel, Western Digital, USA Kevin Pedretti, Sandia National Laboratories, USA Amer Qouneh, Western New England University, USA Carlos Reaño, Queen’s University Belfast, UK Adrian Reber, Redhat, Germany Riccardo Rocha, CERN, Europe Borja Sotomayor, University of Chicago, USA Jonathan Sparks, Cray, USA Kurt Tutschku, Blekinge Institute of Technology, Sweden John Walters, USC ISI, USA Yasuhiro Watashiba, Osaka University, Japan Chao-Tung Yang, Tunghai University, Taiwan Paper Submission-Publication Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, keywords, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in a Springer LNCS volume. The format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Abstract, Paper Submission Link: edas[dot]info/newPaper.php?c=26973 Lightning Talks Lightning Talks are non-paper track, synoptical in nature and are strictly limited to 5 minutes. They can be used to gain early feedback on ongoing research, for demonstrations, to present research results, early research ideas, perspectives and positions of interest to the community. Submit abstract via the main submission link. General Information The workshop is one day in length and will be held in conjunction with the International Supercomputing Conference - High Performance (ISC) 2019, June 21-25, Frankfurt, Germany.

1 0

[libvirt-users] Error in launching chasis
by abhishek jain 18 Dec '19

18 Dec '19

Hi I am new to Libvirt and is starting Chassis but getting following error qemu-system-x86_64:-netdev tap,id=net0,ifname=tap01,vhost=on,script=no,downscript=no: tap: open vhost char device failed:Operation not permitted What could be the reason RegardsAbhishek

2 1

[libvirt-users] Change in treatment of qcow2 with chained backing files in v5.10.0?
by Jens John 17 Dec '19

17 Dec '19

Hello list, upon upgrading from libvirt v5.9.0 -> v5.10.0, libvirt started calling qemu differently causing the VM operating system to not be found. I'm wondering whether I'm chasing a bug, or have to otherwise fix my domain config (created by virt-manager). To start with, I have a Windows 7 domain based on the following images: windows7-base.qcow2: QEMU QCOW2 Image (v3), 53687091200 bytes windows7-Office2013.qcow2: QEMU QCOW2 Image (v3), has backing file (path windows7-taintable.qcow2), 80530636800 bytes windows7-taintable.qcow2: QEMU QCOW2 Image (v3), has backing file (path windows7-base.qcow2), 53687091200 bytes The VM must be launched with image windows7-Office2013.qcow2. Using the domain config [1] with a <disk> section <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/joj/lib/vm/windows/windows7-Office2013.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> libvirt 5.9.0 is calling qemu 4.2.0 like [2], and libvirt 5.10.0 like [3], the differences being (5.9.0 1st, 5.10.0 2nd lines) [--drive file=/home/joj/lib/vm/windows/windows7-Office2013.qcow2,format=qcow2,if=none,id=drive-virtio-disk0-] {+-blockdev {"driver":"file","filename":"/home/joj/lib/vm/windows/windows7-taintable.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":true,"driver":"raw","file":"libvirt-2-storage"} -blockdev {"driver":"file","filename":"/home/joj/lib/vm/windows/windows7-Office2013.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}+} -device [-virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1-] {+virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=libvirt-1-format,id=virtio-disk0,bootindex=1+} As you can see, 5.10.0 is expanding the backing file chain, not leaving that to qemu. Under 5.10.0, I get an Operating System not Found error, under 5.9.0, with the shorter -drive argument, everything works as desired. Can you perhaps advise me how I either fix the domain spec [1] to get libvirt to use a true equivalent to the old qemu invocation as I don't think this is a qemu problem, or how I can turn the new-style JSON parametrization off? Other suggestions how to tackle this would also be much appreciated. --- [1] https://0x0.st/z0KM.xml [2] https://0x0.st/z0K1.txt [3] https://0x0.st/z0Kj.txt

2 2

[libvirt-users] Request to be allotted a project or a feature in pipeline
by Utsav Parmar 16 Dec '19

16 Dec '19

To whom it may concern, I'm Utsav Parmar, pursuing my B. Tech in Computer Engineering. I like to work on new technologies and am currently looking for open-source projects to contribute to. As it may turn out, I've got a college project in my curriculum this semester under “Software Development Practice”, and I'd like to work upon a project and/or a feature in pipeline spanning over 3 months in Libvirt organization as a part of the same college project. My mentor cum professor has already agreed for the same, given that I get approval from one of the maintainers. So, if possible, will you please allot me something to work upon? Thank you for your time. Looking forward to hearing from you. Regards, Utsav Parmar

2 1

[libvirt-users] nvme, spdk and host linux version
by Mauricio Tavares 13 Dec '19

13 Dec '19

I have been following the patches on nvme support on the list and was wondering: If I wanted to build a vm host to be on the bleeding edge for nvme and spdk fun in libvirt, which linux distro -- fedora/ubuntu/centos/etc -- should I pick?

4 5

[libvirt-users] What's the best way to make use of VLAN interfaces with VMs?
by Richard Achmatowicz 05 Dec '19

05 Dec '19

Hello I have a problem with attaching VMs to a VLAN interface. Here is my setup: I have several physical hosts connected by a physical switch. Each host has two NICs leading to the switch, which have been combined into a team, team0. Each host a has a bridge br1, which has team0 as a slave. So communication between hosts is based on the IP address of bridge br1 on each host. Up until recently, using libvirt and KVM, I was creating VMs which had one interface attached the default virtual network and one interface attached to the bridge: virt-install ... --network network=default --network bridge=br1 ... I would then statically assign an IP address to the bridge interface on the guest when installing the OS. A few days ago, a VLAN was introduced to split up the network. I created a new VLAN interface br1.600 on each of the hosts. My initial attempt was to do try this: virt-install ... --network network=default --network bridge=br1.600 ... which did not work. It then dawned on me that a VLAN interface and a bridge aren't treated the same. So I started to look for ways to allow my VMs to bind to this new interface. This would seem to be a common situation. What is the best way to work around this? Both the host bridge and the host VLAN interface already have their assigned IP addresses and appear like this in libvirt: [root@clusterdev01 ]# ifconfig br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.110 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::1e98:ecff:fe1b:276d prefixlen 64 scopeid 0x20<link> ether 1c:98:ec:1b:27:6d txqueuelen 1000 (Ethernet) RX packets 833772 bytes 2976958254 (2.7 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 331237 bytes 23335124 (22.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br1.600: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.110 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::1e98:ecff:fe1b:276d prefixlen 64 scopeid 0x20<link> ether 1c:98:ec:1b:27:6d txqueuelen 1000 (Ethernet) RX packets 189315 bytes 9465744 (9.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 302 bytes 30522 (29.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@clusterdev01]# virsh iface-list --all Name State MAC Address --------------------------------------------------- br1 active 1c:98:ec:1b:27:6d br1.600 active 1c:98:ec:1b:27:6d [root@clusterdev01 sysadmin]# virsh iface-dumpxml br1.600 <interface type='vlan' name='br1.600'> <protocol family='ipv4'> <ip address='192.168.1.110' prefix='24'/> </protocol> <protocol family='ipv6'> <ip address='fe80::1e98:ecff:fe1b:276d' prefix='64'/> </protocol> <link state='up'/> <vlan tag='600'> <interface name='br1'/> </vlan> </interface> I tried following some suggestions which wrapped the vlan interface in a bridge interface, but in ended up trashing the br1.600 interface which was originally defined on the host. Is there a failsafe way to deal with such a situation? Am I doing something completely wrong here? In would like br1.600 to behave like br1 ..... Any suggestions or advice greatly appreciated. Richard

2 5

[libvirt-users] Converting LVM to qcow2
by ort_libvirt＠bergersen.no 04 Dec '19

04 Dec '19

Hi! I need to convert a KVM virtual machine from LVM to a qcow2 image, and wonder if this is the best way to do it (*1): [$] qemu-img convert -O qcow2 /dev/vg_name/lv_name/ /var/lib/libvirt/images/image_name.qcow2 If this is the best way to do this, will this keep the information on: /dev/vg_name/lv_name/ untouched? Thanks, and please point me towards another mailing list if this it not right place to ask questions related to qemu-img! Best regards, Richard Taubo *1) Via: http://nocoast-tech.blogspot.com/2010/05/converting-kvm-guests-from-lvm-to-…

3 3