- Users - libvirt List Archives

[libvirt-users] assigning PCI addresses with bus > 0x09
by Riccardo Ravaioli 05 Jan '19

05 Jan '19

Hi, My goal is to assign PCI addresses to a number of devices (network interfaces, disks and PCI devices in PCI-passthrough) without delegating to libvirt the generation of those values. This should give me more control and for sure more predictability over the hardware configuration of a virtual machine and consequently the name of the interfaces in it. I'm using libvirt 4.3.0 to create qemu/KVM virtual machines running Linux (Debian Stretch). So, for every device of the type mentioned above, I add this line: <address type='pci' domain='0x0000' bus='0x__' slot='0x__' function='0x0'/>, ... with values from 00 to ff in the bus field, and from 00 to 1f in the slot field, as described in the documentation. Long story short, I noticed that as soon as I assign values > 0x09 to the bus field, the serial console hangs indefinitely, in both Debian and Ubuntu. The VM seems to be started correctly and its state is "running"; in the XML file created by libvirt, I see all controllers from 0 the largest bus value I assigned, so everything from that side seems ok. What am I missing here? Thanks! Riccardo

3 6

[libvirt-users] guest runs into watch dog reset
by b f31415 04 Jan '19

04 Jan '19

I'm spinning up a guest, using virt-install. i'm passing the guest a single vcpu and many network interfaces. On the guest side all the interfaces are initially in the down state. I've notice then when I manually bring a specific one of these interfaces up (eg the 64th interface), the guest system hangs. Doing an "strace ifconfig etX up", it looks like the system hangs when doing the ioctl to bring the interface up. This guest is 18.04. Host is 16.04. Are there any qemu/virt commands i can run from the host which would provide me a better understanding as to why the guest gets into this hung state? If I pass two vcpu, I don't suffer from this hang issue. Thanks

1 0

[libvirt-users] avoiding PCI bus 8 / using PCI function / virt-install
by b f31415 03 Jan '19

03 Jan '19

I’m using virt-install to spin up VMs. At times I have a need to spin up VMs which have 100s of interfaces. I ran into the PCI issue mentioned in this previous thread based on how virt-install assigns PCI addresses to interfaces: https://www.redhat.com/archives/libvirt-users/2018-December/msg00064.html Using the info mention there I was able to part hand / part sw re-write an XML where I would remove PCI bus references above the value of 8 and re-address the per interface PCI info to use the function field (I don’t need hot pluggable). But the process I’ve built is brittle. Wondering what options i might have to better deal with this PCI issue. Is there a way to tell virt-install, when building the info it passes to qemu, to use the function field during the PCI assignment process so as to support many more interfaces before hitting the PCI bus == 8 issue? If not, is there a way with one of the virt command line tools to create the XML (with the PCI addresses specified) so that I can process that XML and re-write the PCI addressing values? Right now the only way I’ve been able to get that detailed XML file is to 1) virt-install and let the VM begin the boot process and then do a 2) virsh dumpxml and then 3) virsh destroy/undefine that VM, 4) modify the XML and then 5) virsh create ./modified.xml. Is there a cleaner way to do this? Thanks

3 4

[libvirt-users] Network filters with clean-traffic not working on Debian Stretch
by fatal 03 Jan '19

03 Jan '19

Hello, I'm recently stumbled over the libvirt network filter capabilities and got pretty excited. Unfortunately I'm not able to get the the "clean-traffic" filterset working. I'm using a freshly installed Debian Stretch with libvirt, qemu and KVM. My config snippet looks as follows: sudo virsh edit <VM> [...] <interface type='bridge'> <mac address='52:54:00:0c:14:07'/> <source bridge='br0'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.10.1.2'/> </filterref> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:0c:24:17'/> <source bridge='br1'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='172.16.1.2'/> </filterref> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> [...] I restarted the VM from within the VM, did a "virsh reboot <VM>", restarted libvirtd and even did a reboot of the host - just to be sure. Unfortunately neither "iptables -L" nor "ebtables --list" show any entries added by libvirt. Also omitting the "parameter name='IP'" part didn't change anything. There are no error messages in /var/log/syslog nor in /var/log/libvirt/qemu/<VM> My main references were: https://libvirt.org/firewall.html https://libvirt.org/formatnwfilter.html https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht… https://www.berrange.com/posts/2011/10/03/guest-mac-spoofing-denial-of-serv… Any help really would be much appreciated! Thanks a lot! Sam

3 3

[libvirt-users] luks ecrypted storage poll - lvm - possible?
by lejeczek 21 Dec '18

21 Dec '18

hi everyone, do we get to encrypt lvm pools in/with libvirt? I'm on Centos 7.x but see mention of it, not even on the net. Or in other words - can guests(lxc I'm thinking of) run off ecrypted lvm where at least the part when dev gets luksOpened is taken care of by libvirt? many thanks, L.

3 3

[libvirt-users] Shutdown problem from virsh
by Thomas Munfort 21 Dec '18

21 Dec '18

Hi everyone, On a server running Debian 9, I have multiple KVM guests automatically started at boot by libvirtd.service and running in the background. When I shutdown this server, libvirtd.service automatically and gracefully shut them all down first. So, every thing is fine so far. Recently, I've added an additional KVM guest and this one does not respond to a shutdown command from virsh and therefore messes up the shutdown of the whole Debian 9 server. The things is, this additional KVM guest is not a regular Linux guest. It is DiskStation Manager (DSM) 6.2 from Synology (with XPEnology as the boot loader). I know this setup isn't supported by libvirt nor Synology. Nonetheless, I wonder if anyone would have idea on that matter ? Even some suggestions might help me find what needs fixing. Thank you, Best regards, Thomas M.

1 2

[libvirt-users] CfP for VHPC ‘19: HPC Virtualization Paper Registration due January 25, 2019 - 14th Virtualization in High-Performance Cloud Computing Workshop@ISC
by VHPC 19 21 Dec '18

21 Dec '18

Please accept our apologies if you receive multiple copies of this Call for Papers ==================================================================== CALL FOR PAPERS 14th Workshop on Virtualization in High-Performance Cloud Computing (VHPC '19) held in conjunction with the International Supercomputing Conference - High Performance, June 16-20, 2019, Frankfurt, Germany. (Springer LNCS Proceedings) ==================================================================== Date: June 20, 2019 Workshop URL: http://vhpc.org Abstract Submission Deadline: January 25, 2019 Springer LNCS, rolling abstract submission Abstract/Paper Submission Link: https://edas.info/newPaper.php?c=25685 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. 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 on Containers and VMs - Containerized applications with OS-level virtualization - Lightweight applications with Unikernels - HP-as-a-Service each major topic encompassing design/architecture, management, performance management, modeling and configuration/tooling: Design / Architecture: - Containers and OS-level virtualization (LXC, Docker, rkt, Singularity, Shifter, i.a.) - Hypervisor support for heterogeneous resources (GPUs, co-processors, FPGAs, etc.) - Hypervisor extensions to mitigate side-channel attacks ([micro-]architectural timing attacks, privilege escalation) - VM & Container trust and security models - Multi-environment coupling, system software supporting in-situ analysis with HPC simulation - Cloud reliability, fault-tolerance and high-availability - Energy-efficient and power-aware virtualization - Containers inside VMs with hypervisor isolation - Virtualization support for emerging memory technologies - Lightweight/specialized operating systems in conjunction with virtual machines - Hypervisor support for heterogeneous resources (GPUs, co-processors, FPGAs, etc.) - Novel unikernels and use cases for virtualized HPC environments - ARM-based hypervisors, ARM virtualization extensions Management: - Container and VM management for HPC and cloud environments - HPC services integration, services to support HPC - Service and on-demand scheduling & resource management - Dedicated workload management with VMs or containers - Workflow coupling with VMs and containers - Unikernel, lightweight VM application management - Environments and tools for operating containerized environments (batch, orchestration) - Novel models for non-HPC workload provisioning on HPC resources Performance Measurements and Modeling: - Performance improvements for or driven by unikernels - Optimizations of virtual machine monitor platforms and hypervisors - Scalability analysis of VMs and/or containers at large scale - Performance measurement, modeling and monitoring of virtualized/cloud workloads - Virtualization in supercomputing environments, HPC clusters, HPC in the cloud Configuration / Tooling: - Tool support for unikernels: configuration/build environments, debuggers, profilers - Job scheduling/control/policy and container placement in virtualized environments - Operating MPI in containers/VMs and Unikernels - Software defined networks and network virtualization - GPU virtualization operationalization 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 January 25, 2019 - Abstract Registration deadline Apr 19th, 2019 - Paper submission deadline (Springer LNCS) May 3, 2019 - Acceptance notification June 20th, 2019 - Workshop Day July 10th, 2019 - Camera-ready version due Chair Michael Alexander (chair), University of Vienna, Austria Anastassios Nanos (co-chair), SunLight.io, UK Andrew Younge (co-chair), Sandia National Laboratories Program committee Stergios Anastasiadis, University of Ioannina, Greece Jakob Blomer, CERN, Europe Eduardo César, Universidad Autonoma de Barcelona, Spain Stephen Crago, USC ISI, USA Tommaso Cucinotta, St. Anna School of Advanced Studies, Italy Christoffer Dall, Columbia University, USA Patrick Dreher, MIT, USA Kyle Hale, Northwestern University, USA Brian Kocoloski, Washington University, USA John Lange, University of Pittsburgh, USA Giuseppe Lettieri, University of Pisa, Italy Qing Liu, Oak Ridge National Laboratory, USA Nikos Parlavantzas, IRISA, France Kevin Pedretti, Sandia National Laboratories, USA Amer Qouneh, Western New England University, USA Carlos Reaño, Queen’s University Belfast, UK Borja Sotomayor, University of Chicago, USA Joe Stubbs, Texas Advanced Computing Center, USA Anata Tiwari, San Diego Supercomputer Center, USA Kurt Tutschku, Blekinge Institute of Technology, Sweden Yasuhiro Watashiba, Osaka University, Japan Chao-Tung Yang, Tunghai University, Taiwan Na Zhang, VMware, USA 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. Format Guidelines: ftp://ftp.springernature.com/cs-proceeding/llncs/llncs2e.zip Abstract, Paper Submission Link: https://edas.info/newPaper.php?c=25685 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 16-20, Frankfurt, Germany.

1 0

[libvirt-users] win10 network speed issue
by Michael Taboada 20 Dec '18

20 Dec '18

Hi there, I'm running a windows 10 vm on an arch linux host, linux 4.19.9.arch1-1, qemu 3.1.0-1, libvirt (from git) 4.10.0.45.g34eca98522-1, and recently have been having issues with network speeds on the windows vm. It started out getting 300-400 mb down, now it's down to about 10-30. Can anyone think of anything that might have caused this? I tried switching the network type to virtio, but that didn't make much of a difference. Afaik I don't think I've changed anything config-wise in the windows vm. Also the network type is nat. -Michael.

1 0

[libvirt-users] vms doesn't coomunicate via network
by daggs 20 Dec '18

20 Dec '18

Greetings, I have two vms, one is a router and the other one is a client, for some reason, the client vm is unable get ip via dhcp from the router vm. here are outputs: vm1.xml: <interface type='bridge'> <mac address='52:54:00:54:78:be'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> router.xml: <interface type='bridge'> <mac address='52:54:00:f9:bd:fb'/> <source bridge='virbr0'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net1'/> <address type='pci' domain='0x0000' bus='0x0a' slot='0x00' function='0x0'/> </interface> ifconfig: $ busybox ifconfig -a dummy0 Link encap:Ethernet HWaddr CE:2E:DD:15:8A:0C BROADCAST NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:21428 errors:0 dropped:0 overruns:0 frame:0 TX packets:21428 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1039176 (1014.8 KiB) TX bytes:1039176 (1014.8 KiB) virbr0 Link encap:Ethernet HWaddr 52:54:00:7E:27:AF inet6 addr: fe80::5054:ff:fe7e:27af/64 Scope:Link inet6 addr: fdab:9802:eb52:0:5054:ff:fe7e:27af/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:530861 errors:0 dropped:0 overruns:0 frame:0 TX packets:85 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:591914339 (564.4 MiB) TX bytes:4042 (3.9 KiB) virbr0-dummy Link encap:Ethernet HWaddr 52:54:00:7E:27:AF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:141357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:32288355 (30.7 MiB) vnet0 Link encap:Ethernet HWaddr FE:54:00:8B:66:C1 inet addr:10.0.0.3 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fdab:9802:eb52:0:fc54:ff:fe8b:66c1/64 Scope:Global inet6 addr: fe80::fc54:ff:fe8b:66c1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:261801 errors:0 dropped:0 overruns:0 frame:0 TX packets:438289 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:42370344 (40.4 MiB) TX bytes:895415306 (853.9 MiB) vnet1 Link encap:Ethernet HWaddr FE:54:00:F9:BD:FB inet6 addr: fe80::fc54:ff:fef9:bdfb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:531064 errors:0 dropped:0 overruns:0 frame:0 TX packets:262 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:599366518 (571.5 MiB) TX bytes:27088 (26.4 KiB) /etc/network/interface: $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug enx503eaa4f9dcd #iface enx503eaa4f9dcd inet dhcp #allow-hotplug enp0s31f6 #iface enp0s31f6 inet dhcp allow-hotplug vnet0 iface vnet0 inet dhcp auto virbr0-dummy iface virbr0-dummy inet manual pre-up /sbin/ip link add virbr0-dummy type dummy up /sbin/ip link set virbr0-dummy address 52:54:00:7e:27:af auto virbr0 iface virbr0 inet manual hwaddress ether 19:7c:3b:92:ec:ee bridge_ports virbr0-dummy any ideas what cen be the issue? Thanks, Dagg.

2 2

[libvirt-users] "virsh list --all" is intermittently causing a shutdown client to boot?
by Peter Kukla 15 Dec '18

15 Dec '18

Hello, I have a CentOS 7 client running on a CentOS 7 server. "virsh --version" reports that 3.9.0 is being used. I'm issuing a "virsh shutdown" command to shutdown the client. I then confirm that the client has actually shutdown using "virsh list --all". Lately I've been seeing instances where I shutdown the client, turn away to work on something else, and then turn back to find that the client has booted again. Initially I thought I was mistaken, and that I somehow hadn't properly shutdown the client, but further experimentation shows that's definitely not the case. I've been able to reproduce this repeatedly using the following steps. 1. Run "virsh shutdown CLIENT"2. Wait ~30-60 seconds3. Run "virsh list --all; virsh console CLIENT" If I run "virsh console CLIENT" on its own when the client is in a shutdown state, I get the expected "error: The domain is not running" message. If I omit step #2 and run step #3 immediately after shutting down the client, virsh also complains that the client's not started and refuses to open a console. However, if I add a pause -- step 2, above -- between the shutdown and the "list --all" commands, then "list --all" shows that the client is running, and a console is opened to the VM. I have confirmed that the client boot is definitely being started by the "list --all" command (and not being started by something else while I'm not looking) by combining the "list --all" and "console" commands in step 3. This is ensuring that the console is started as soon as the "list --all" is complete, and the resulting screen output shows the BIOS boot options quickly followed by the kernel boot messages being dumped to the console. I can watch the entire boot process from start to finish. That pause between the shutdown and the "list --all" is critical. I've shutdown the client and then immediately followed it up with the command: watch virsh list --all ...which will run the "list --all" command every 2 seconds. This will run indefinitely without triggering the boot, which eliminates the possibility of the boot occurring due to the amount of time since the shutdown. It may be that other virsh commands are also causing the client to boot, but thus far I've only reproduced it using the list --all command. Can anyone tell me why this is happening? A bug? Something in my config? Something else? Thanks in advance, -peter .

4 6