- Users - libvirt List Archives

[libvirt-users] how to use LV(container) created by lxc-create?
by lejeczek 20 Oct '18

20 Oct '18

hi everyone, how can I use a LV created by lxc in libvirt guest domain? You know, you lxc-create with LV as backstore for a container(ubuntu in my case) and now you want to give to libvit. That, I thought would be a very common case but I failed to find a good howto on how one: lxc-create(lvm) => let libvirt take control over it. Or it's not how you would do it at all? many thanks, L.

2 1

[libvirt-users] LXC with --filesystem - control/impose filesystem(/ in container) size limits - how?
by lejeczek 19 Oct '18

19 Oct '18

hi guys container was created off a template with --dir. Is it even possible? I mean, as it is with filesystem, without moving/migrating to LVM, ZFS, etc? The very brute solution which comes to my mind - xfs project quotas - if it even could work. But that outside of libvirt/lxc. many thanks, L.

1 0

[libvirt-users] KVM + libvirt + nftables without iptables?
by Roman Vesely 19 Oct '18

19 Oct '18

Hi everyone, I use Debian 9.5 Stretch and NFTABLES as a firewall. Using NFTABLES together with IPTABLES is not recommended, but libvirt depends on IPTABLES. Is it safe to run libvirt + kvm + virsh without IPTABLES? By the doc https://libvirt.org/firewall.html, IPTABLES are used for settingup filtering which I do not need. Thanks, Roman

3 4

[libvirt-users] pcie-expander-bus doesn't support pcie-pci-bridge and pcie-switch-upstream-port
by Han Han 18 Oct '18

18 Oct '18

In libvirt, I found pcie-expander-bus controller doesn't support pcie-to-pci-bridge and pcie-switch-upstream-port. Version: libvirt-4.9 # cat /tmp/c.xml ... <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... # virsh -k0 -K0 define /tmp/c.xml error: Failed to define domain from /tmp/c.xml error: XML error: The device at PCI address 0000:01:00.0 cannot be plugged into the PCI controller with index='1'. It requires a controller that accepts a pcie-to-pci-bridge. # cat /tmp/b.xml ... <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-switch-upstream-port'> <model name='x3130-upstream'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... # virsh -k0 -K0 define /tmp/b.xml error: Failed to define domain from /tmp/b.xml error: XML error: The device at PCI address 0000:01:00.0 cannot be plugged into the PCI controller with index='1'. It requires a controller that accepts a pci-switch-upstream-port. In function virDomainPCIAddressBusSetModel, I find pcie-expander-bus only supports pcie-root-port and dmi-to-pci-bridge 353 case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_EXPANDER_BUS: 354 ┆ /* 32 slots, no hotplug, only accepts pcie-root-port or 355 ┆ ┆* dmi-to-pci-bridge 356 ┆ ┆*/ 357 ┆ bus->flags = (VIR_PCI_CONNECT_TYPE_PCIE_ROOT_PORT | 358 ┆ ┆ ┆ ┆ ┆ VIR_PCI_CONNECT_TYPE_DMI_TO_PCI_BRIDGE); 359 ┆ bus->minSlot = 0; 360 ┆ bus->maxSlot = VIR_PCI_ADDRESS_SLOT_LAST; 361 ┆ break; But it works in qemu: # /usr/libexec/qemu-kvm -machine q35 -m 1024 -device pxb-pcie,bus_nr=250,id=pci.1,bus=pcie.0,addr=0x4 -device pcie-pci-bridge,id=pci.250,bus=pci.1,addr=0x0 -device pcie-pci-bridge,id=pci.251,bus=pci.1,addr=0x1 -spice port=5902,addr=0.0.0.0,disable-ticketing /var/lib/libvirt/images/q35.qcow2 So why pcie-expander-bus doesn't these two controllers? For any concerns in libvirt? Thank you~ -- Best regards, ----------------------------------- Han Han Quality Engineer Redhat. Email: hhan(a)redhat.com Phone: +861065339333

4 4

[libvirt-users] Serial ports: vm vs bare metal
by Lars Kellogg-Stedman 16 Oct '18

16 Oct '18

I'm running libvirt under Fedora 28. I would like to attach a USB device to a VM, but when I select "Redirect USB Device" from the "Virtual Machine" menu in virt-manager and then select the device, I get the error: USB redirection error spice-client-error-quark: Could not redirect [device name] at 1-11: Error setting USB device node ACL: 'Not authorized' (0) There are no additional log messages acccompanying this in either the journal or in audit.log. It's not a selinux issue. The "Details" dropdown in the error dialog helpfully adds "USB redirection error". What do I do with this error message? I'm not even sure what it's trying to tell me. Thanks, -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ |

3 4

[libvirt-users] snapshots with virsh in a pacemaker cluster
by Lentes, Bernd 15 Oct '18

15 Oct '18

Hi, i have a two node cluster with virtual guests as resources. I'd like to snapshot the guests once in the night and thought i had a procedure. But i realize that things in a cluster are a bit more complicated than expected :-)) I will shutdown the guests to have a clean snapshot. I can shutdown the guests via pacemaker. But then arises the first problem: When i issue a "virsh snapshot-create-as" libvirt needs the domain name as a parameter. but libvirt does not know the domains any longer. When the guests are shutdown a "virsh list --all" on both nodes does not show any domain. A look in the respective resource agent VirtualDomain explains why: The domain is started with virsh create: "# The 'create' command guarantees that the domain will be # undefined on shutdown, ... OK: Now i could of course define all domains with a virsh define. But then i have immediately the next problem. Now i'd create the snapshots with "virsh snapshot-create-as" and starts the domains afterwards via cluster. But let's assume i issue that on node 1 and some guests are started afterwards via pacemaker on node 2. I can't predict on which node the guests are starting. Then i don't get a snapshot, right ? What to do ? Bernd -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen [ mailto:bernd.lentes@helmholtz-muenchen.de | bernd.lentes(a)helmholtz-muenchen.de ] phone: +49 89 3187 1241 fax: +49 89 3187 2294 [ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ] wer Fehler macht kann etwas lernen wer nichts macht kann auch nichts lernen Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: NN Stellv.Aufsichtsratsvorsitzender: MinDirig. Dr. Manfred Wolter Geschaeftsfuehrer: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, Dr. rer. nat. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

3 3

[libvirt-users] Device lease hot unplug and events
by Milan Zamazal 15 Oct '18

15 Oct '18

Hi, when working on hot unplugs of various devices, I've found out that hot unplugging <lease> device doesn't generate VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event. <lease> also doesn't have an alias, so it wouldn't be identifiable in the corresponding callback. Is this difference from other hotpluggable devices intentional? If yes, is there any better way of checking that <lease> removal is completed than querying and examining the domain XML? From user's point of view, it would be best if I could simply handle the device removal event the same way as with other devices. Thanks, Milan

2 4

[libvirt-users] How to explain this libvirt oddity w.r.t machine types?
by Kashyap Chamarthy 15 Oct '18

15 Oct '18

Context: The baremetal host previously had QEMU 2.11. But I manually downgraded the QEMU version (via `dnf downgrade qemu-system-x86`); now it is at 2.10: $ rpm -q qemu-system-x86 qemu-system-x86-2.10.2-1.fc27.x86_64 The guest is offline. Let's see (in a couple of ways) what machine type it has while it is dormant: # virsh dumpxml cirros | grep -i machine= <type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type> # grep machine= /etc/libvirt/qemu/cirros.xml <type arch='x86_64' machine='pc-i440fx-2.10'>hvm</type> Okay, now edit the guest XML and carefully remove the "machine='pc-i440fx-2.10'" bit---to see what machine type will libvirt (libvirt-daemon-kvm-4.0.0-2.fc27.x86_64) default to: # virsh edit cirros Domain cirros XML configuration edited. Now check the machine type again. Bizarrely enough, libvirt "helpfully" auto-adds QEMU *2.11* machine type, which is obviously no longer on the system! # grep machine= /etc/libvirt/qemu/cirros.xml <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> # virsh dumpxml cirros | grep -i machine= <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> How to explain this? Is this even a "valid test"? (To undo the nuisance, obviously, I had to `virsh edit cirros` again and change it to 2.10.) Note, I *don't* have 2.11 QEMU on the system: # rpm -qa | grep -E 'qemu.*2.11' # echo $? 1 * * * It's getting late, and I should stop staring at screens. -- /kashyap

2 5

[libvirt-users] live migration via unix socket
by David Vossel 12 Oct '18

12 Oct '18

Hey, Over in KubeVirt we're investigating a use case where we'd like to perform a live migration within a network namespace that does not provide libvirtd with network access. In this scenario we would like to perform a live migration by proxying the migration through a unix socket to a process in another network namespace that does have network access. That external process would live on every node in the cluster and know how to correctly route connections between libvirtds. virsh example of an attempted migration via unix socket. virsh migrate --copy-storage-all --p2p --live --xml domain.xml my-vm qemu+unix:///system?socket=destination-host-proxy-sock In this example, the src libvirtd is able to establish a connection to the destination libvirtd via the unix socket proxy. However, the migration-uri appears to require either tcp or rdma network connection. If I force the migration-uri to be a unix socket, I receive an error [1] indicating that qemu+unix is not a valid transport. Technically with qemu+kvm I believe what we're attempting should be possible (even though it is inefficient). Please correct me if I'm wrong. Is there a way to achieve this migration via unix socket functionality this using Libvirt? Also, is there a reason why the migration uri is limited to tcp/rdma Thanks! - David [1] https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_migration.c#L2…

4 7

[libvirt-users] how "safe" is blockcommit ?
by Lentes, Bernd 12 Oct '18

12 Oct '18

Hi, currently i'm following https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit. I 'm playing around with it and it seems to be quite nice. What i want is a daily consistent backup of my image file of the guest. I have the idea of the following procedure: - Shutdown the guest (i can live with a downtime of a few minutes, it will happen in the night). And i think it's the only way to have a real clean snapshot - create a snapshot with snapshot-create-as: snapshot-create-as guest testsn --disk-only - start the guest again. Changes will now go into the overlay, as e.g. inserts in a database - rsync the base file to a cifs server. With rsync not the complete, likely big file is transferred but just the delta - blockcommit the overlay: blockcommit guest /path/to/testsn --active --wait --verbose --pivot - delete the snapshot: snapshot-delete guest --snapshotname testsn --metadata - remove the overlay Is that ok ? How "safe" is blockcommit on a running guest ? It's possible that during the rsync, when the guest is running, some inserts are done in a database. Is it safe to copy the new sectors (i assume that's what blockcommit does) under a running database ? Or is it only safe doing blockcommit on a stopped guest ? Thanks for any answer. Bernd P.S. Is the same procedure possible when the guest disk(s) reside directly in a plain logical volume, without a file system in-between ? -- Bernd Lentes Systemadministration Institut für Entwicklungsgenetik Gebäude 35.34 - Raum 208 HelmholtzZentrum münchen [ mailto:bernd.lentes@helmholtz-muenchen.de | bernd.lentes(a)helmholtz-muenchen.de ] phone: +49 89 3187 1241 fax: +49 89 3187 2294 [ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ] wer Fehler macht kann etwas lernen wer nichts macht kann auch nichts lernen Helmholtz Zentrum Muenchen Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH) Ingolstaedter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrer: Prof. Dr. med. Dr. h.c. Matthias H. Tschoep, Heinrich Bassler, Dr. rer. nat. Alfons Enhsen Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

4 5