- Users - libvirt List Archives

[libvirt-users] Virtual Smartcard GPG
by roky＠openmailbox.org 29 Apr '15

29 Apr '15

Hi. Is is possible to use GPG on the host instead of NSS with virtual smartcards? Please document how or add support for it. Can a virtual smartcard make the host less secure? If there are bugs in GPG/NSS backend on the host can they be abused by untrusted code in the vm?

1 0

[libvirt-users] How does the libvirt deal with the vnet mac address
by wh.h＠foxmail.com 29 Apr '15

29 Apr '15

How does the libvirt deal with the vnet mac address? Greetings, if I establish a network for the VM (hypervisor is KVM) using bridge in the virt-manager , a vnet0 device is created . There are some relationships about mac address between the vnet0 device in the hypervisor and the ethX device in the VM, for example : the mac address of vnet0 is FE:54:00:84:E3:62 the mac address of ethX in the VM is 52:54:00:84:E3:62 two mac addresses above are almost the same except the first part of the address . but if I created a tap device manually , tunctl -t tap0 -u root brctl addif br0 tap0 and add tap0 to the VM, I will find that mac address between the tap0 device in the hypervisor and the ethX device in the VM will totally different . so I think that libvirt must do something about the mac address handling, could you please kindly tell me something about this ? I have found a function in libvirt-0.10.2.8\src\util\ virnetdevtap.c int virNetDevTapCreateInBridgePort(const char *brname, char **ifname, const virMacAddrPtr macaddr, const unsigned char *vmuuid, int *tapfd, virNetDevVPortProfilePtr virtPortProfile, virNetDevVlanPtr virtVlan, unsigned int flags) { …. virMacAddr tapmac; if (virNetDevTapCreate(ifname, tapfd, flags) < 0) return -1; /* We need to set the interface MAC before adding it * to the bridge, because the bridge assumes the lowest * MAC of all enslaved interfaces & we don't want it * seeing the kernel allocate random MAC for the TAP * device before we set our static MAC. */ virMacAddrSet(&tapmac, macaddr); if (!(flags & VIR_NETDEV_TAP_CREATE_USE_MAC_FOR_BRIDGE)) { if (macaddr->addr[0] == 0xFE) { /* For normal use, the tap device's MAC address cannot * match the MAC address used by the guest. This results * in "received packet on vnetX with own address as source * address" error logs from the kernel. */ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Unable to use MAC address starting with " "reserved value 0xFE - '%02X:%02X:%02X:%02X:%02X:%02X' - "), macaddr->addr[0], macaddr->addr[1], macaddr->addr[2], macaddr->addr[3], macaddr->addr[4], macaddr->addr[5]); goto error; } tapmac.addr[0] = 0xFE; /* Discourage bridge from using TAP dev MAC */ //the first part of mac address is set to 0xFE. } if (virNetDevSetMAC(*ifname, &tapmac) < 0) goto error; …. } How does the libvirt establish the arp table in the hypervisor if the vnet0 device in the hypervisor and the ethX device in the VM is different? If I want to create tap device manually , how should I deal with the mac address ?I have setup the mac address of the tap0 device in the hypervisor and the ethX device in the VM in the same way with libvirt , but the network of VM cannot work. weihua wh.h(a)foxmail.com wh.h(a)foxmail.com

3 5

[libvirt-users] Remove Virtual bridge and DNSMASQ
by mimicafe＠gmail.com 25 Apr '15

25 Apr '15

I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in bridged network mode, however I still have the default virtual network bridge/interfaces and dnsmasq on the host. What I am trying to understand is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and Vnet1*) still play any role. If not, can I remove them? On most virtual hosts I see they are left around even when a network bridge has been manually setup and the default virtual network bridge/interfaces and dnsmasq are not serve any purpose. Thanks Mimi [bigfoot@localhost ~]$ ifconfig br0 Link encap:Ethernet HWaddr E2:59:52:12:34:4C inet addr:135.17.1XX.XX Bcast:135.17.1XX.XX Mask:255.255.255.128 inet6 addr: fe80::ea39:35ff:fe12:948e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:564577 errors:0 dropped:0 overruns:0 frame:0 TX packets:303315 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:566465184 (540.2 MiB) TX bytes:83532692 (79.6 MiB) eth0 Link encap:Ethernet HWaddr E2:59:52:12:34:4C inet6 addr: fe80::ea39:35ff:fe12:948e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:806142 errors:0 dropped:0 overruns:0 frame:0 TX packets:450977 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:711888772 (678.9 MiB) TX bytes:175377460 (167.2 MiB) Interrupt:28 Memory:f7100000-f7120000 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:16436 Metric:1 RX packets:276793 errors:0 dropped:0 overruns:0 frame:0 TX packets:276793 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:551259266 (525.7 MiB) TX bytes:551259266 (525.7 MiB) *virbr0 Link encap:Ethernet HWaddr 52:54:00:2A:1B:AF* * inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0* * UP BROADCAST RUNNING MULTICAST 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:0* * RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)* *vnet0 Link encap:Ethernet HWaddr FE:54:00:A0:8D:50* * inet6 addr: fe80::fc54:ff:fea0:8d50/64 Scope:Link* * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* * RX packets:124812 errors:0 dropped:0 overruns:0 frame:0* * TX packets:343055 errors:0 dropped:0 overruns:0 carrier:0* * collisions:0 txqueuelen:500* * RX bytes:55075362 (52.5 MiB) TX bytes:138488556 (132.0 MiB)* *vnet1 Link encap:Ethernet HWaddr FE:54:00:71:A8:78* * inet6 addr: fe80::fc54:ff:fe71:a878/64 Scope:Link* * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* * RX packets:17834 errors:0 dropped:0 overruns:0 frame:0* * TX packets:318816 errors:0 dropped:0 overruns:1 carrier:0* * collisions:0 txqueuelen:500* * RX bytes:2279102 (2.1 MiB) TX bytes:20534286 (19.5 MiB)* [bigfoot@localhost ~]$

3 7

[libvirt-users] CfP Virtualization in High-Performance Cloud Computing Workshop (VHPC '15)
by VHPC 15 25 Apr '15

25 Apr '15

================================================================= CALL FOR PAPERS 10th Workshop on Virtualization in High-Performance Cloud Computing (VHPC '15) held in conjunction with Euro-Par 2015, August 24-28, Vienna, Austria (Springer LNCS) ================================================================= Date: August 25, 2015 Workshop URL: http://vhpc.org Paper Submission Deadline: May 22, 2015 CALL FOR PAPERS Virtualization technologies constitute a key enabling factor for flexible resource management in modern data centers, cloud environments, and increasingly in HPC as well. Providers need to dynamically manage complex infrastructures in a seamless fashion for varying workloads and hosted applications, independently of the customers deploying software or users submitting highly dynamic and heterogeneous workloads. Thanks to virtualization, we have the ability to manage vast computing and networking resources dynamically and close to the marginal cost of providing the services, which is unprecedented in the history of scientific and commercial computing. Docker et al. OS-level virtualization, with its capability to isolate multiple user-space environments allows for their co-existence within the same OS kernel. It promises to provide many of the advantages of machine virtualization with high levels of responsiveness and performance; coupled with lightweight OSs it forms a potent architecture with promise to become a mainstream environment for HPC workloads. Machine virtualization, with its capability to enable consolidation of multiple under-utilized 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; I/O Virtualization allows physical network adapters to take traffic from multiple VMs; network virtualization, with its capability to create logical network overlays that are independent of the underlying physical topology and IP addressing, provides the fundamental ground on top of which evolved network services can be realized with an unprecedented level of dynamicity and flexibility; These technologies have to be inter-mixed and integrated in an intelligent way, to support workloads that are increasingly demanding in terms of absolute performance, responsiveness and interactivity, and have to respect well-specified Service- Level Agreements (SLAs), as needed for industrial-grade provided services. 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, and lightning talks, limited to 5 minutes. Presentations may be accompanied by interactive demonstrations. TOPICS Topics of interest include, but are not limited to: - Virtualization in supercomputing environments, HPC clusters, cloud HPC and grids - OS-level virtualization including container runtimes (Docker, rkt et al.) - Lightweight compute node operating systems/VMMs - Optimizations of virtual machine monitor platforms, hypervisors and - Hypervisor and network virtualization QoS and SLAs - Cloud based network and system management for SDN and NFV - Management, deployment and monitoring of virtualized environments - Performance measurement, modelling and monitoring of virtualized/cloud workloads - Programming models for virtualized environments - Cloud reliability, fault-tolerance, high-availability and security - Heterogeneous virtualized environments, virtualized accelerators, GPUs and co-processors - Optimized communication libraries/protocols in the cloud and for HPC in the cloud - Topology management and optimization for distributed virtualized applications - Cluster provisioning in the cloud and cloud bursting - Adaptation of emerging HPC technologies (high performance networks, RDMA, etc..) - I/O and storage virtualization, virtualization aware file systems - Job scheduling/control/policy in virtualized environments - Checkpointing and migration of VM-based large compute jobs - Cloud frameworks and APIs - Energy-efficient / power-aware virtualization Important Dates April 29, 2015 - Abstract registration May 22, 2015 - Full paper submission June 19, 2015 - Acceptance notification October 2, 2015 - Camera-ready version due August 25, 2015 - Workshop Date TPC CHAIR Michael Alexander (chair), TU Wien, Austria Anastassios Nanos (co-chair), NTUA, Greece Balazs Gerofi (co-chair), RIKEN Advanced Institute for Computational Science, Japan PROGRAM COMMITTEE Stergios Anastasiadis, University of Ioannina, Greece Costas Bekas, IBM Zurich Research Laboratory, Switzerland Jakob Blomer, CERN Ron Brightwell, Sandia National Laboratories, USA Roberto Canonico, University of Napoli Federico II, Italy Julian Chesterfield, OnApp, UK Patrick Dreher, MIT, USA William Gardner, University of Guelph, Canada Kyle Hale, Northwestern University, USA Marcus Hardt, Karlsruhe Institute of Technology, Germany Iftekhar Hussain, Infinera, USA Krishna Kant, Temple University, USA Eiji Kawai, National Institute of Information and Communications Technology, Japan Romeo Kinzler, IBM, Switzerland Kornilios Kourtis, ETH, Switzerland Nectarios Koziris, National Technical University of Athens, Greece Massimo Lamanna, CERN Che-Rung Roger Lee, National Tsing Hua University, Taiwan William Magato, University of Cincinnati, USA Helge Meinhard, CERN Jean-Marc Menaud, Ecole des Mines de Nantes France Christine Morin, INRIA, France Amer Qouneh, University of Florida, USA Seetharami Seelam, IBM Watson Research Center, USA Josh Simons, VMWare, USA Borja Sotomayor, University of Chicago, USA Kurt Tutschku, Blekinge Institute of Technology, Sweden 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, key words, 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 the Springer LNCS series - 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: http://www.springer.de/comp/lncs/authors.html Submission Link: https://easychair.org/conferences/?conf=europar2015ws GENERAL INFORMATION The workshop is one day in length and will be held in conjunction with Euro-Par 2015, 24-28 August, Vienna, Austria

1 0

[libvirt-users] Unknown segfault
by Fl＠sh 23 Apr '15

23 Apr '15

Unknown sefault: http://itmag.es/2HxqM Why this might happen? Maybe i'm close last virConnectRef in threads? (but this is unlikely). Or maybe another reason? -- Fl@sh

3 5

[libvirt-users] Mounting directory as readonly within LXC
by Harish Vishwanath 22 Apr '15

22 Apr '15

Hello Is there a way to mount a directory as readonly when using LXC with libvirt? Something like: <filesystem type="mount"> <source dir="/sw/py27/python2.7_x86_64"/> <target dir="/opt//py27"/> <readonly/> </filesystem> The documentation says readonly only works with KVM/QEMU. Regards, Harish

2 2

[libvirt-users] QEMU interface type=ethernet
by Brian Rak 22 Apr '15

22 Apr '15

With Libvirt under modern kernels, you can't use <interface type='ethernet'> unless QEMU is running as root. Running qemu as root is not ideal, but I was able to track down the issue to this linux change: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c… Which means that if you're seeing errors like this: 2015-03-02T18:00:51.243477Z qemu-kvm: -netdev tap,script=/tmp/vnet380622.sh,id=hostnet1: could not open /dev/net/tun: Operation not permitted 2015-03-02T18:00:51.243518Z qemu-kvm: -netdev tap,script=/tmp/vnet380622.sh,id=hostnet1: Device 'tap' could not be initialized They can be resolved like this: 1) Edit /etc/libvirt/qemu.conf, and add "/dev/net/tun" to the cgroup_device_acl option 2) Run: setcap cap_net_admin+eip /bin/qemu-system-x86_64 This will give QEMU CAP_NET_ADMIN when it runs. Make sure you review `man capabilities` to see what capabilities this actually gets qemu. The downside here is that in the event a guest somehow breaks out of qemu, CAP_NET_ADMIN gives them a bunch of scary permissions that could result in you having a seriously bad day (it's enough permissions to MITM all the machine's traffic, which could easily result in compromise) It looks to me like libvirt already has the ability to create tap devices and pass them into qemu (src/util/virnetdevtap.c - virNetDevTapCreateInBridgePort), however you need to actually be using a bridged network to do this. There is no way to have libvirt just create a tap device and leave the rest to user defined scripts. I don't think I have the necessary knowledge to add that feature in a generic way, but it seems like it would be pretty handy. I'll probably just work around it by removing the virNetDevBridgeAddPort call from our version of libvirt.

2 3

[libvirt-users] Libvirt disk API
by fu lirong 21 Apr '15

21 Apr '15

Hi all: I am studying Libvirt API , I am wondering the API about the disk manage is TBD(to be difine). The edition is libvirt 0.7.5 ,but the edition is too old ,The website is http://libvirt.org/guide/html/Application_Development_Guide-Introduction.ht… So, if I want to manage the VM disk , for example read the disk, what should I do ? Sincerely thanks a lot

2 1

[libvirt-users] <qemu:commandline> domain XML tag is not working?
by Chengyuan Li 21 Apr '15

21 Apr '15

Hi, I tried to enable virtio-blk data plane feature for VMs in my openstack environment, the hypervisor is ubuntu 14.04, libvirt 1.2.2 and QEMU 2.0. As nova doesn't support that parameter yet, I did belows 1. nova boot a VM with raw disk image. 2. nova stop the VM. 3. run "virsh edit <instance-id>" on the hyprvisor node, and adding below into instance xml just before </domain>. However, the <qemu:commandline> part is ignored and not saved after closing virsh edit, seems that libvirt rejected these changes. Is there any XML syntax error here? Or libvirt doesn't support <qemu:commandline> tag? <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.drive-virtio-disk0.x-data-plane=on'/> </qemu:commandline> Regards, Chengyuan.

4 6

[libvirt-users] libvirt and guest processes
by dt sweval 21 Apr '15

21 Apr '15

Hi I wanted to find out if there is way to list all the running processes in a guest VM from the hypervisor. Like the output of 'ps -ef' from inside the guest VM, but without logging in or ssh into it. Thanks dtsweval

4 5