- Users - libvirt List Archives

[libvirt-users] Convincing libvirt to create a bridge device?
by Lars Kellogg-Stedman 07 Mar '16

07 Mar '16

I was hoping that I could delegate creation of bridge devices to libvirt for address-less bridges, in order to not have to deal with the various ways distributions handle persistent network configuration, but while this creates a libvirt network... <network> <name>provision</name> <forward mode='bridge'/> <bridge name='brprov'/> </network> ...it doesn't actually create the bridge. Configuring the bridge using either <forward mode="route"/> or <forward mode="nat"/> *will* create the bridge device, but both of these require assigning an address to the bridge which means I have to suddenly worry about IPAM and conflicts with local networks. I look at the various interface-related commands, and there is an "iface-bridge" command but this requires a physical interface. Is there any way to convince libvirt to create the bridge device for a <forward mode='bridge'/> network? -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/

2 2

[libvirt-users] [libvirt-1.3.2]'Disconnected from qemu:///session due to I/O error'
by Predrag Ivanovic 05 Mar '16

05 Mar '16

Hi. Since the update to libvirt-1.3.2, virsh keeps disconnecting from qemu:///session. Weirdly enough, qemu:///session works fine for root, and qemu:///system works for both the user and the root. With the same configuration(tarball with files from /etc/libvirt attached), libvirt-1.3.1 works without problems. From the virsh debug log(attached): --- grep error virsh.log.1.3.2 2016-03-03 19:19:20.338+0000: 5589: error : virNetSocketReadWire:1613 : End of file while reading data: Input/output error 2016-03-03 19:19:46.261+0000: 5578: error : virConnectUnregisterCloseCallback:1282 : Requested operation is not valid: A different callback was requested 2016-03-03 19:22:59.308+0000: 14487: error : virNetSocketReadWire:1613 : End of file while reading data: Input/output error 2016-03-03 19:23:29.247+0000: 14486: error : virConnectUnregisterCloseCallback:1282 : Requested operation is not valid: A different callback was requested 2016-03-03 19:24:49.521+0000: 14487: error : virKeepAliveTimerInternal:143 : internal error: connection closed due to keepalive timeout 2016-03-03 19:25:17.043+0000: 14486: error : virConnectUnregisterCloseCallback:1282 : Requested operation is not valid: A different callback was requested 2016-03-03 19:25:47.110+0000: 14487: error : virNetSocketReadWire:1613 : End of file while reading data: Input/output error 2016-03-03 19:26:18.573+0000: 14486: error : virConnectUnregisterCloseCallback:1282 : Requested operation is not valid: A different callback was requested 2016-03-03 19:28:24.142+0000: 14665: error : virNetSocketReadWire:1613 : End of file while reading data: Input/output error 2016-03-03 19:28:55.091+0000: 14664: error : virConnectUnregisterCloseCallback:1282 : Requested operation is not valid: A different callback was requested --- From the virt-manager.log (attached): --- [Thu, 03 Mar 2016 18:39:38 virt-manager 24388] DEBUG (connection:1310) Error polling connection qemu:///session if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: internal error: client socket is closed if ret == -1: raise libvirtError ('virConnectDomainEventDeregisterAny() failed', conn=self) libvirtError: internal error: client socket is closed [Thu, 03 Mar 2016 19:07:14 virt-manager 5191] ERROR (create:667) Error setting create wizard conn state. if ret is None: raise libvirtError ('virConnectGetCapabilities() failed', conn=self) libvirtError: internal error: client socket is closed [Thu, 03 Mar 2016 19:07:15 virt-manager 5191] DEBUG (connection:1310) Error polling connection qemu:///session if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: internal error: client socket is closed if ret == -1: raise libvirtError ('virConnectDomainEventDeregisterAny() failed', conn=self) libvirtError: internal error: client socket is closed [Thu, 03 Mar 2016 19:08:19 virt-manager 5191] DEBUG (connection:1310) Error polling connection qemu:///session if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: internal error: client socket is closed if ret == -1: raise libvirtError ('virConnectDomainEventDeregisterAny() failed', conn=self) libvirtError: internal error: client socket is closed [Thu, 03 Mar 2016 19:11:19 virt-manager 5191] DEBUG (connection:1310) Error polling connection qemu:///system if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: internal error: client socket is closed if ret == -1: raise libvirtError ('virConnectDomainEventDeregisterAny() failed', conn=self) libvirtError: internal error: client socket is closed --- qemu:///system errors above are due to restarting libvirtd, once virt-manager connected to it, it stayed connected. This is with qemu-2.5.0. I could try libvirt master from git, but will it break libvirt-python/virt-manager? Btw, is building libvirt with '--enable-debug' sufficient for useful gdb debug report, or do you need anything else? Thank you. Pedja

2 2

[libvirt-users] network checksum offloading broken using virtio
by Dennis Jacobfeuerborn 05 Mar '16

05 Mar '16

Hi, with recent guest installs (both centos 5 and 7) on centos 7 hosts I seem to have to disable checksum offloading using "ethtool -K eth0 tx off" in order to allow traffic to flow a specific route. Basically the guest is installed with IP 192.168.21.10 and a default gateway of 192.168.21.254. Up until that point I can ssh into the system normally. There exists an OpenVPN System with the IP 192.168.21.1 that choses client IP's for the vpn connections from the pool 192.168.20.0/24. In order to pass the reponses back to the OpenVPN system I installed the route "192.168.20.0/24 via 192.168.21.1 dev eth0". When I now ping the IP 192.168.21.10 through the VPN connection this works fine but when I try to ssh into that system the connection just hangs. Looking at a tcpdump I noticed that the checksum for the packets weren't quite right so I issued a "ethtool -K eth0 tx off" and suddenly everything worked as expected. What is strange here is that I'm seeing this with both CentOS 5 and CentOS 7 guests and only when dealing with th routed traffic and not the regular one. Does anyone have an idea what is going on here? Could this be an issue with the virtio driver? Regards, Dennis

2 2

[libvirt-users] Why are virsh vol-upload/vol-download so slow?
by Lars Kellogg-Stedman 04 Mar '16

04 Mar '16

I was interested in using 'virsh vol-upload' and 'virsh vol-download', rather than mucking about directly with the filesystem. But while simply copying the image is relatively quick: # ls -l /var/lib/libvirt/images/centos-7-cloud.qcow2 -rw-r--r--. 1 qemu qemu 1004994560 Apr 15 2015 centos-7-cloud.qcow2 # time cp /var/lib/libvirt/images/centos-7-cloud.qcow2 /tmp/myimage.qcow2 real 0m10.829s user 0m0.024s sys 0m1.668s Trying to do the same thing with `virsh vol-download` is glacial: # time virsh vol-download --pool default centos-7-cloud.qcow2 /tmp/myimage.qcow2 I killed it after 10 minutes: real 10m20.775s user 10m19.451s sys 0m1.887s After which is was about halfway through: # ls -l /tmp/myimage.qcow2 -rw-r--r--. 1 root root 564920248 Mar 4 11:11 /tmp/myimage.qcow2 What is up with that? -- Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/

2 5

[libvirt-users] control virtualbox from virsh
by jeremy.huylebroeck＠orange.com 03 Mar '16

03 Mar '16

Hi. I am running virtualbox 4.3 on Mac OS X 10.11.12 and libvirtd 1.3.1 (installed with brew). I want to control the virtual machines via virsh. On libvirtd, I enabled tcp mode, removed all the authentication etc.. It's a development environment, so no worries here. It allows me to make a call such as: virsh –c vbox+tcp://172.30.5.51/session list —all 172.30.5.51 being my Mac IP address. Virsh connects successfully to libvirtd (I see my request in the log) but the "list —all" returns an error. virsh -c vbox+tcp://172.30.5.51/session list --all error: Failed to list domains error: invalid connection pointer in virGetDomain Based on the debug logs, it appears the vbox driver is properly used 2016-03-03 22:27:44.415+0000: 18446744073709551615: debug : do_open:1003 : name "vbox:///session" to URI components: scheme vbox server <null> user <null> port -1 path /session (…) 2016-03-03 22:27:44.416+0000: 18446744073709551615: debug : do_open:1050 : trying driver 4 (VBOX) ... 2016-03-03 22:27:44.416+0000: 18446744073709551615: debug : virArchFromHost:181 : Mapped x86_64 to 32 (x86_64) 2016-03-03 22:27:44.416+0000: 18446744073709551615: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fa41950b2c0 classname=virCaps 2016-03-03 22:27:44.416+0000: 18446744073709551615: debug : virArchFromHost:181 : Mapped x86_64 to 32 (x86_64) 2016-03-03 22:27:44.416+0000: 18446744073709551615: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fa41a208da0 classname=virDomainXMLOption 2016-03-03 22:27:44.416+0000: 18446744073709551615: debug : vboxConnectOpen:460 : in vboxOpen 2016-03-03 22:27:44.416+0000: 18446744073709551615: debug : do_open:1065 : driver 4 VBOX returned SUCCESS But later there is this error: 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virThreadJobSet:96 : Thread 18446744073709551615 (virNetServerHandleJob) is now running job remoteDispatchConnectListAllDomains 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCleanupTimeouts:526 : Cleanup 2 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : remoteDispatchConnectListAllDomainsHelper:1219 : server=0x7fa419700040 client=0x7fa4196037c0 msg=0x7fa41a201280 rerr=0x700000415d40 args=0x7fa419602c90 ret=0x7fa419600ad0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCleanupHandles:575 : Cleanup 5 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virConnectListAllDomains:6701 : conn=0x7fa41950afe0, domains=0x700000415c40, flags=3 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollMakePollFDs:401 : Prepare n=0 w=1, f=5 e=1 d=0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollMakePollFDs:401 : Prepare n=1 w=2, f=7 e=1 d=0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollMakePollFDs:401 : Prepare n=2 w=3, f=9 e=1 d=0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollMakePollFDs:401 : Prepare n=3 w=4, f=11 e=1 d=0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollMakePollFDs:401 : Prepare n=4 w=8, f=12 e=1 d=0 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCalculateTimeout:338 : Calculate expiry of 2 timers 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCalculateTimeout:346 : Got a timeout scheduled for 1457044069419 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCalculateTimeout:359 : Schedule timeout then=1457044069419 now=1457044064420 2016-03-03 22:27:44.420+0000: 18446744073709551615: debug : virEventPollCalculateTimeout:369 : Timeout at 1457044069419 due in 4999 ms 2016-03-03 22:27:44.420+0000: 18446744073709551615: info : virEventPollRunOnce:641 : EVENT_POLL_RUN: nhandles=5 timeout=4999 2016-03-03 22:27:44.421+0000: 18446744073709551615: error : virGetDomain:203 : invalid connection pointer in virGetDomain 2016-03-03 22:27:44.422+0000: 18446744073709551615: debug : virThreadJobClear:121 : Thread 18446744073709551615 (virNetServerHandleJob) finished job remoteDispatchConnectListAllDomains with ret=-1 The full log is here http://pastebin.com/raw/83Fgs5MZ I've been digging around but can't find anything I should change in my configuration or in virtualbox. I poked in the libvirt code, but I am not a C developer, so can't really figure it out. Any chance somebody sees a solution to this? There must be something obvious that I don't see… Thanks! _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

[libvirt-users] Configuring default network/storage for qemu:///session
by catern＠catern.com 03 Mar '16

03 Mar '16

Hi libvirt-user, If I run (as a normal user): virsh -c qemu:///session net-list --all virsh -c qemu:///session pool-list --all I see a default network and a default pool. And indeed, these appear in the persistent configuration. It seems these are created the first time libvirtd is (auto)started in qemu:///session mode. Is it possible to configure the attributes of the default network and default pool that are created? This is to provide configuration for newly created users. Normally I would just put some default configuration in /etc/skel. But it seems that a UUID element needs to be present in the network and pool configuration. And so for my configuration to be correct I either need to wrap add some special sauce to adduser that generates several UUIDs and puts them in the configuration, or just generate the UUIDs in advance and let them be copied to all users. Currently I'm taking the second option, so all users have the same UUID for their default network and pool. I don't know if that might hurt me in the future, but it certainly seems distasteful. Thanks!

3 3

[libvirt-users] libvirt_driver_storage.so /usr/lib64/../lib64/libfl.so.2: undefined symbol: yylex
by Matthew Schumacher 03 Mar '16

03 Mar '16

Hello List, I'm trying to get libvirt to work on slackware64-current (slackware64-14.2 beta) and while it compiles just fine, it refuses to run because of an undefined symbol: 2016-03-01 20:09:26.822+0000: 27849: error : virDriverLoadModule:73 : failed to load module /usr/lib64/libvirt/connection-driver/libvirt_driver_storage.so /usr/lib64/../lib64/libfl.so.2: undefined symbol: yylex I'm not really doing anything odd, here is my configure options in my package building script: ./configure \ --prefix=/usr \ --libdir=/usr/lib64 \ --bindir=/usr/sbin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --localstatedir=/var \ --mandir=/usr/man \ --docdir=/usr/doc/libvirt-1.3.3 \ --enable-static=no \ --enable-shared=yes \ --with-yajl \ --with-python=/usr \ --with-qemu-group=users \ --with-init-script=none \ --with-storage-iscsi Looks like the old slackware64-14.1 had flex compiled statically and the new version is an SO, so I figure that's why this didn't happen on the older slackware. Any thoughts on how to fix this?

1 1

[libvirt-users] Live migration - backing file
by Marc-Aurèle Brothier - Exoscale 03 Mar '16

03 Mar '16

Hi! I'm testing the live migration on libvirt + KVM, the VMs are using non-shared local storage only. If I run a live migration with --copy-storage-full, the final disk file on the remote host after the migration has a full blown size of the specified value (10G) in my case, instead of the few MB on the source host before the migration. Running qemu-img I can see that the ref for the backing file is gone. on source host: $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 18MB $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f image: 3129b8a8-eca4-4b05-878a-66c2771b501f file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 17M cluster_size: 65536 backing file: /var/lib/libvirt/images/34fa65ce-483b-4ffa-88f8-75f6ebf670c1 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false >> I run a migration with --live --copy-storage-all on destination host: $ ls -lh 3129b8a8-eca4-4b05-878a-66c2771b501f gives me 11GB $ qemu-img info 3129b8a8-eca4-4b05-878a-66c2771b501f image: 3129b8a8-eca4-4b05-878a-66c2771b501f file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 817M cluster_size: 65536 Format specific information: compat: 0.10 refcount bits: 16 Is there a way to keep the backing file reference for live migration or planned development (if this file is also available on the destination host)? I also tried with --copy-storage-inc but the disk image on the destination is invalid as it lost the backing file and only copied the diff, so the base image files are gonne. Moreover, the file size on the disk is also of 10GB with that parameter. Regards, Marc-Aurèle Brothier Exoscale

1 1

[libvirt-users] ceph and libxl errors attaching device
by Iban Cabrillo 03 Mar '16

03 Mar '16

Dear, I need to attach some ceph (0.94.6) block devices to our openstack (kilo) running instances (xen 4.4) . Nova is able to create volumes, attach a detach (alt least there are no errors) The hypervisor can see the blockdevice: # rbd -p volumes ls volume-xxxxxxxx-7342-434b-9xx1-d046bcxxxxfd And the instance xml seems to be ok: ................. <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none'/> <auth username='cinder'> <secret type='ceph' uuid='xxxxxxxx-e53a-4xx7-9bc9-9bcc41xxxxe4'/> </auth> <source protocol='rbd' name='volumes/volume-xxxxxxxx-7342-434b-9xx1-d046bcxxxxfd'> <host name='10.10.3.1' port='6789'/> <host name='10.10.3.2' port='6789'/> <host name='10.10.3.3' port='6789'/> </source> <target dev='xvdd' bus='xen'/> <serial>xxxxxxxx-7342-434b-9xx1-d046bcxxxxfd</serial> </disk> But there is no way to attach the device to running machine, I only see this error on libxl : libxl: debug: libxl.c:3538:libxl_device_disk_add: ao 0x7fe248006080: create: how=(nil) callback=(nil) poller=0x7fe24000ce20 libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk vdev=xvdd spec.backend=qdisk libxl: debug: libxl_event.c:618:libxl__ev_xswatch_deregister: watch w=0x7fe248001780: deregister unregistered libxl: debug: libxl_event.c:1591:libxl__ao_complete: ao 0x7fe248006080: complete, rc=0 libxl: debug: libxl.c:3538:libxl_device_disk_add: ao 0x7fe248006080: inprogress: poller=0x7fe24000ce20, flags=ic libxl: debug: libxl_event.c:1563:libxl__ao__destroy: ao 0x7fe248006080: destroy Seems like qdisk backend is not able to manage the volume Any idea? -- ############################################################################ Iban Cabrillo Bartolome Instituto de Fisica de Cantabria (IFCA) Santander, Spain Tel: +34942200969 PGP PUBLIC KEY: http://pgp.mit.edu/pks/lookup?op=get&search=0xD9DF0B3D6C8C08AC ############################################################################ Bertrand Russell: *"El problema con el mundo es que los estúpidos están seguros de todo y los inteligentes están llenos de dudas*"

2 2

[libvirt-users] VM's in a HA-configuration - synchronising vm config files
by Lentes, Bernd 02 Mar '16

02 Mar '16

Hi, i'd like to establish a HA-Cluster with two nodes. My services will run inside vm's, the vm's are stored on a FC SAN, so every host has access to the vm's. But how can i keep the config files (xml-files under /etc/libvirt/qemu) synchronised ? Is there a possibility to store the config files somewhere else ? E.g. a partitition with ocfs2 on the SAN ? If not, what would you do ? Otherweise i'm thinking of a cron-job who synchronises the file each minute with rsync. Bernd -- Bernd Lentes Systemadministration institute of developmental genetics Gebäude 35.34 - Raum 208 HelmholtzZentrum München bernd.lentes(a)helmholtz-muenchen.de phone: +49 (0)89 3187 1241 fax: +49 (0)89 3187 2294 Wer Visionen hat soll zum Hausarzt gehen Helmut Schmidt 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. Guenther Wess, Dr. Alfons Enhsen, Renate Schlusen (komm.) Registergericht: Amtsgericht Muenchen HRB 6466 USt-IdNr: DE 129521671

3 4