- Users - libvirt List Archives

[libvirt-users] Detecting Co-residency of VMs on KVM
by Shikhar Agarwal 16 Feb '12

16 Feb '12

I am doing an experiment which involves detecting co-resident VMs (testing if 2 VMs are on the same physical machine) on KVM. I have tried using cache covert channel, but this test does not work if the VMs are on different processors within the same host as the caches are not shared then. If I use the tools netperf and iperf to differentiate using network channels, I am not getting clear results. This is because the network is really good (10 Gbps). I believe there are better and more reliable ways for the same. Please suggest some of these. The idea is to find some resource (like memory, disk, etc) that is shared by the VMs and try to run some benchmarks that thrash this resource. Another idea is to take advantage of some optimization that kvm might be doing internally. Please help me. Thank you Shikhar Agarwal Undergraduate Senior IIT-Delhi

3 3

[libvirt-users] Detach devices using Libvirt+Xen
by Daniel Espling 16 Feb '12

16 Feb '12

Hi! We're struggling to get device detaching to work reliably using Xen. We can reliably use the same code to manage devices using Libvirt+KVM without any problems. We've tested this on Xen with both CD-ROM and USB devices without success. See below for detailed descriptions. Thankful for any help! Regards, Daniel Espling --- For CD-ROM, we can mount them using attach-device but cannot remove them using the correspoding call to detach-device: cdrom7.xml contains: <disk type='file' device='cdrom'> <driver name='file' type='raw'/> <source file='/opt/diskimages/test7.iso'/> <target dev='hdc' bus='ide'/> <readonly/> </disk> eject.xml contains: <disk type='block' device='cdrom'> <driver name='file'/> <target dev='hdc' bus='ide'/> <readonly/> </disk> cdrom8.xml is identical to cdrom7.xml apart from the .iso file used. # virsh attach-device deb cdrom7.xml Device attached successfully # virsh detach-device deb cdrom7.xml error: no such device in deb # virsh attach-device deb eject.xml error: Failed to attach device from eject.xml error: POST operation failed: xend_post: error from xen daemon: (xend.err 'Device 5632 not connected') # virsh update-device deb cdrom8.xml --persistent error: Failed to update device from cdrom8.xml error: POST operation failed: xend_post: error from xen daemon: (xend.err 'Device 5632 not connected') dumpxml shows the cdrom device attached exactly as it's defined in the xml. Using virsh we're able to use "virsh detach-disk deb hdc" to unmount the CD-ROM, but we need to be able to do this using the python API. We cannot find a corresponding call to detach-disk and we therefore have to rely on detach-device instead, right? Are there any flags we can use for detachDeviceFlags() to replicate the functionality of detach-disk? ---- Similarly for USB devices, we can mount them OK but not remove them using the corresponding call to detach-device. Calling detach-disk works, but again we need to find the corresponding call for this function using the python API. One thing we've found with mounting USB devices is that they seem to be mounted on the SCSI bus instead of the USB one as specified: Example: usb7.xml contains: <disk type='file' device='disk'> <driver name='file' type='raw'/> <source file='/opt/diskimages/test7.iso'/> <target dev='sda' bus='usb'/> <readonly/> </disk> dumpxml shows: <disk type='file' device='disk'> <driver name='file'/> <source file='/opt/diskimages/test7.iso'/> <target dev='sda' bus='scsi'/> <readonly/> </disk> # virsh attach-device deb usb7.xml Device attached successfully Test attaching again (expected to fail): # virsh attach-device deb usb7.xml error: Failed to attach device from usb7.xml error: Requested operation is not valid: target 'sda' already exists `-testgrid7.leeds.ac.uk /opt/recontext # virsh detach-device deb usb7.xml error: no such device in deb ---- Relevant info: Compiled against library: libvir 0.9.9 Using library: libvir 0.9.9 Using API: Xen 0.9.9 Running hypervisor: Xen 4.0.0 Running CentOS 5.5 (final) Linux 2.6.32.24 #3 SMP Fri Oct 29 16:22:02 BST 2010 x86_64 x86_64 x86_64 GNU/Linux

2 3

[libvirt-users] qcow2 performance
by Stefan G. Weichinger 15 Feb '12

15 Feb '12

Greets, I have to research performance-issues of a W2003-VM within KVM. Right now it's a qcow2-image-file w/ default settings within libvirt (configured by vmm ...) My question: what caching to use? writeback/writethrough/etc ... what to use for data integrity while not getting ultraslow performance? Found https://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf Is there any other list/doc what to use and why? Thanks, Stefan

5 10

Re: [libvirt-users] [libvirt] Fail to import available VM image
by Laine Stump 15 Feb '12

15 Feb '12

On 02/14/2012 11:01 AM, Jun Koi wrote: > On Tue, Feb 14, 2012 at 11:47 PM, Alex Jia <ajia(a)redhat.com> wrote: >> Hi Jun, >> I assume you haven't changed libvirt default URI, it may be a issue, >> I want to know whether it works for you if you explicitly specify >> --connect qemu:///system with virt-install? I think a root reason >> probably is your disk image location, the log said it can't find >> storage volume, if you put img.winp under the /var/lib/libvirt/images, >> then give a disk absolute path to virt-install, Does it work for you? > ok, i change the command a bit, and it went further. > here is how i did: > > (1) compiled everything from source, then install (make install) to my Ubuntu > > (2) start libvirtd on commandline > # libvirtd -d > > (3) import my KVM image to libvirt > > $ virt-install --connect qemu:///system -n winxp -r 800 --accelerate > --vnc -v --noautoconsole --import -f /home/jun/img/img.winxp > > it failed, and the log is like below: > > .... > [Tue, 14 Feb 2012 23:51:49 virt-install 3831] DEBUG (cli:326) > Requesting libvirt URI qemu:///system > [Tue, 14 Feb 2012 23:51:51 virt-install 3831] DEBUG (cli:328) Received > libvirt URI qemu:///system > [Tue, 14 Feb 2012 23:51:52 virt-install 3831] DEBUG (virt-install:259) > Requesting virt method 'hvm', hv type 'default'. > [Tue, 14 Feb 2012 23:51:52 virt-install 3831] DEBUG (virt-install:469) > Received virt method 'hvm' > [Tue, 14 Feb 2012 23:51:52 virt-install 3831] DEBUG (virt-install:470) > Hypervisor name is 'kvm' > [Tue, 14 Feb 2012 23:51:52 virt-install 3831] ERROR (cli:439) Error in > network device parameters: Virtual network 'default' has not been > started. > [Tue, 14 Feb 2012 23:51:52 virt-install 3831] DEBUG (cli:440) > Traceback (most recent call last): > File "/usr/local/lib/python2.6/dist-packages/virtinst/cli.py", line > 884, in get_networks > dev = parse_network(guest, netstr, mac=mac) > File "/usr/local/lib/python2.6/dist-packages/virtinst/cli.py", line > 1642, in parse_network > bridge=opts.get("bridge")) > File "/usr/local/lib/python2.6/dist-packages/virtinst/VirtualNetworkInterface.py", > line 153, in __init__ > self.network = network > File "/usr/local/lib/python2.6/dist-packages/virtinst/XMLBuilderDomain.py", > line 309, in new_setter > fset(self, val, *args, **kwargs) > File "/usr/local/lib/python2.6/dist-packages/virtinst/VirtualNetworkInterface.py", > line 257, in set_network > "started.") % newnet) > ValueError: Virtual network 'default' has not been started. A very common cause of this problem is that a systemwide instance of dnsmasq is already (erroneously) listening on the bridge created by libvirt for the default network. I took your email as an oppurtunity to write an entry in the new Troubleshooting section of the libvirt wiki. It will explain to you how to solve your problem (*if* this is your problem, of course :-). http://wiki.libvirt.org/page/Virtual_network_%27default%27_has_not_been_sta… If that ends up not being your problem, please reply to this message, but sending the reply to libvirt-users(a)redhat.com (I also Cc'ed this message there) rather than to libvir-list(a)redhat.com. (The former is the official list for user questions about libvirt, whil libvir-list is intended for for people discussing the code.) > i guess perhaps just starting "libvirtd -d" on commandline is not > enough. do i need a script to configure and start libvirtd properly > for me? > and it seems i must configure the virtual network somehow? The "default" network should already be there as part of the stock install.

3 7

[libvirt-users] QEMU hook on restore
by Székelyi Szabolcs 14 Feb '12

14 Feb '12

Hi, I'm using libvirt 0.8.3. It looks like to me that when a QEMU domain is restored from save, the hook is called with the "stopped end -" arguments. I've also noticed that the domain description passed to the hook script doesn't contain the network device the host will be attached to (XPath: /domain/devices/interface/target/@dev). Are these a bugs or a features? Thanks, -- cc

3 10

[libvirt-users] libvirtd restore error?
by lee 13 Feb '12

13 Feb '12

Hi qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64 qemu-kvm-tools-0.12.1.2-2.160.el6_1.2.x86_64 libvirt-java-javadoc-0.4.7-1.el6.noarch libvirt-client-0.8.7-18.el6.x86_64 fence-virtd-libvirt-qpid-0.2.1-8.el6.x86_64 ocaml-libvirt-0.6.1.0-6.2.el6.x86_64 libvirt-devel-0.8.7-18.el6.x86_64 libvirt-python-0.8.7-18.el6.x86_64 libvirt-java-0.4.7-1.el6.noarch libvirt-cim-0.5.11-3.el6.x86_64 libvirt-java-devel-0.4.7-1.el6.noarch libvirt-client-0.8.7-18.el6.i686 libvirt-qpid-0.2.22-6.el6.x86_64 fence-virtd-libvirt-0.2.1-8.el6.x86_64 libvirt-0.8.7-18.el6.x86_64 ocaml-libvirt-devel-0.6.1.0-6.2.el6.x86_64 get this error when I try to restore a vm that was 'save'. Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 909, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 1321, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: cannot send monitor command '{"execute":"qmp_capabilities"}': Connection reset by peer the solution was to delete the /var/lib/libvirt/qemu/save directory. Anyone any idea of why? Lee

2 1

[libvirt-users] virt-manager thru window's remote desktop
by Hisao Taguchi 13 Feb '12

13 Feb '12

Hi, I am trying to operate the remote KVM host's virt-manager thru Terminal Server Client. This KVM hosts is CentOS6.0 and running KVM guest and xrdp is installed from "epel" repo. And I'm using fedora 14's Terminal Server Client. After I started Virtual Machine Manager and try to connect to the hypervisor, following error happened. Is there any way to resolve this error? I know that when I use VNC server , this error does not happened, but I want to use Terminal Server rather than VNC, because this doesn't need extra software for windows client PCs. -- Error snip -- Virtual Machine Manager Connection Failure Unable to open a connection to the libvirt management daemon. Libvirt URI is: qemu:///system Verify that: - The 'libvirtd' daemon has been started Details Unable to open connection to hypervisor URI 'qemu:///system': authentication failed Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 992, in_try_open None],flags) File "/usr/lib64/python2.6/site-packages/libvirt.py",line 111,in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: authentication failed -- end -- Hisao

2 3

[libvirt-users] java binding
by Maurizio Paone 12 Feb '12

12 Feb '12

Hi all, I'm trying to use the libvirt event system in order to notify the VM status (VM boot, reboot, crash, etc.). I must use the java binding, so I exposed some calls not present in "Libvirt-java" jna interface: virEventRunDefaultImpl() virEventRegisterDefaultImpl() (and several costant). In my java source I tried to intercept the event, using the "Connection.domainEventRegisterAny( ... )" call , but the "answer" was: "this function is not supported by the connection driver: no event support". No errors issued on the virEventRunDefaultImpl and virEventRegisterDefaultImpl (moreover, both the calls return "0" ). I do not know the libvirt internals, so my question is : it is possible to call the libvirt events calls using java binding? Can you tell me the issues involved in this task? I'm thinking to build a native library and use jni or use jython as alternatives. Thanks, Maurizio

1 0

[libvirt-users] Unable to collect VM metrics for ESX using libvirt
by sethu subbiah 11 Feb '12

11 Feb '12

Hi, I am trying to connect to a server running esx and collect system metrics like cpu usage, network and disk iops. I am able to establish the connection successfully and obtain VM information such as ids, domain names, config xml etc. But I am unable to collect statistics. I am using the python interface and if I do , conn=libvirt.openAuth(uri, auth, 0) dom-conn.lookupByID(id) // Where id is the domain id of the vms netstats=dom.interfaceStats(interface) gives an error libvirt.libvirtError: this function is not supported by the connection driver: virDomainInterfaceStats The same goes for block stats. For the cpu, I used, cpu=dom.info()[4] but, that always returns 0 (I thought it was cumulative and returns a huge value) I have used similar scripts with xen and kvm and it worked well. Can someone tell me what mistake I am doing or if the driver doesnt support these functions, is there any other way of getting the stats ?? Thank you. - Regards, Sethuraman Subbiah Graduate Student - NC state University M.S in Computer Science

2 1

[libvirt-users] virsh migrate results in error: Timed out during operation: cannot acquire state change lock
by Nuno Sousa 11 Feb '12

11 Feb '12

Hi all, Hi have one computer hosting several VM, this particular server is in need of maintenance and has to be shutdown. In order to avoid disrupting the services provided by the VM I intended to migrate the VM to another computer. Computer 1 and 2 do not share any storage. So it is necessary to migrate not only the memory but also any data on the hard-drive. Both computers are running debian squeeze. Virsh is version 0.8.3. I issue this command on server one: sudo LIBVIRT_DEBUG=1 virsh migrate --live --copy-storage-all i00cn1011 qemu+ssh://user@computer2/session > debug.log 2>&1 On virt-manager on computer 1, the VM appears for a few moments as paused, and then disappears. On computer 1 I receive the error: Timed out during operation: cannot acquire state change lock Does anyone know what the problem may be and how to solve it? Next I send all the data returned by virsh. Thanks everyone. user@computer1:~$ cat debug.log 13:52:07.911: debug : virInitialize:339 : register drivers 13:52:07.911: debug : virRegisterDriver:927 : registering Test as driver 0 13:52:07.911: debug : virRegisterNetworkDriver:733 : registering Test as network driver 0 13:52:07.911: debug : virRegisterInterfaceDriver:764 : registering Test as interface driver 0 13:52:07.911: debug : virRegisterStorageDriver:795 : registering Test as storage driver 0 13:52:07.911: debug : virRegisterDeviceMonitor:826 : registering Test as device driver 0 13:52:07.911: debug : virRegisterSecretDriver:857 : registering Test as secret driver 0 13:52:07.911: debug : virRegisterNWFilterDriver:888 : registering Test as network filter driver 0 13:52:07.911: debug : virRegisterDriver:927 : registering Xen as driver 1 13:52:07.911: debug : virRegisterDriver:927 : registering OPENVZ as driver 2 13:52:07.911: debug : vboxRegister:122 : VBoxCGlueInit failed, using dummy driver 13:52:07.911: debug : virRegisterDriver:927 : registering VBOX as driver 3 13:52:07.911: debug : virRegisterNetworkDriver:733 : registering VBOX as network driver 1 13:52:07.911: debug : virRegisterStorageDriver:795 : registering VBOX as storage driver 1 13:52:07.911: debug : virRegisterDriver:927 : registering remote as driver 4 13:52:07.911: debug : virRegisterNetworkDriver:733 : registering remote as network driver 2 13:52:07.911: debug : virRegisterInterfaceDriver:764 : registering remote as interface driver 1 13:52:07.911: debug : virRegisterStorageDriver:795 : registering remote as storage driver 2 13:52:07.911: debug : virRegisterDeviceMonitor:826 : registering remote as device driver 1 13:52:07.911: debug : virRegisterSecretDriver:857 : registering remote as secret driver 1 13:52:07.911: debug : virRegisterNWFilterDriver:888 : registering remote as network filter driver 1 13:52:07.911: debug : virConnectOpenAuth:1498 : name=(null), auth=0x7f3c96c6c7a0, flags=0 13:52:07.911: debug : do_open:1206 : no name, allowing driver auto-select 13:52:07.911: debug : do_open:1243 : trying driver 0 (Test) ... 13:52:07.911: debug : do_open:1249 : driver 0 Test returned DECLINED 13:52:07.911: debug : do_open:1243 : trying driver 1 (Xen) ... 13:52:07.911: debug : do_open:1249 : driver 1 Xen returned DECLINED 13:52:07.911: debug : do_open:1243 : trying driver 2 (OPENVZ) ... 13:52:07.911: debug : do_open:1249 : driver 2 OPENVZ returned DECLINED 13:52:07.911: debug : do_open:1243 : trying driver 3 (VBOX) ... 13:52:07.911: debug : do_open:1249 : driver 3 VBOX returned DECLINED 13:52:07.911: debug : do_open:1243 : trying driver 4 (remote) ... 13:52:07.911: debug : remoteOpen:1120 : Auto-probe remote URI 13:52:07.911: debug : doRemoteOpen:564 : proceeding with name = 13:52:07.911: debug : remoteIO:9886 : Do proc=66 serial=0 length=28 wait=(nil) 13:52:07.911: debug : remoteIO:9961 : We have the buck 66 0x7f3c96d01010 0x7f3c96d01010 13:52:07.912: debug : remoteIODecodeMessageLength:9314 : Got length, now need 64 total (60 more) 13:52:07.912: debug : remoteIOEventLoop:9812 : Giving up the buck 66 0x7f3c96d01010 (nil) 13:52:07.912: debug : remoteIO:9990 : All done with our call 66 (nil) 0x7f3c96d01010 13:52:07.912: debug : remoteIO:9886 : Do proc=1 serial=1 length=40 wait=(nil) 13:52:07.912: debug : remoteIO:9961 : We have the buck 1 0xe671b0 0xe671b0 13:52:07.912: debug : remoteIODecodeMessageLength:9314 : Got length, now need 56 total (52 more) 13:52:07.912: debug : remoteIOEventLoop:9812 : Giving up the buck 1 0xe671b0 (nil) 13:52:07.912: debug : remoteIO:9990 : All done with our call 1 (nil) 0xe671b0 13:52:07.912: debug : remoteIO:9886 : Do proc=110 serial=2 length=28 wait=(nil) 13:52:07.912: debug : remoteIO:9961 : We have the buck 110 0xe671b0 0xe671b0 13:52:07.913: debug : remoteIODecodeMessageLength:9314 : Got length, now need 76 total (72 more) 13:52:07.913: debug : remoteIOEventLoop:9812 : Giving up the buck 110 0xe671b0 (nil) 13:52:07.913: debug : remoteIO:9990 : All done with our call 110 (nil) 0xe671b0 13:52:07.913: debug : doRemoteOpen:922 : Auto-probed URI is qemu:///system 13:52:07.913: debug : doRemoteOpen:941 : Adding Handler for remote events 13:52:07.913: debug : doRemoteOpen:948 : virEventAddHandle failed: No addHandleImpl defined. continuing without events. 13:52:07.913: debug : do_open:1249 : driver 4 remote returned SUCCESS 13:52:07.913: debug : do_open:1269 : network driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1269 : network driver 1 VBOX returned DECLINED 13:52:07.913: debug : do_open:1269 : network driver 2 remote returned SUCCESS 13:52:07.913: debug : do_open:1288 : interface driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1288 : interface driver 1 remote returned SUCCESS 13:52:07.913: debug : do_open:1308 : storage driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1308 : storage driver 1 VBOX returned DECLINED 13:52:07.913: debug : do_open:1308 : storage driver 2 remote returned SUCCESS 13:52:07.913: debug : do_open:1328 : node driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1328 : node driver 1 remote returned SUCCESS 13:52:07.913: debug : do_open:1355 : secret driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1355 : secret driver 1 remote returned SUCCESS 13:52:07.913: debug : do_open:1375 : nwfilter driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1375 : nwfilter driver 1 remote returned SUCCESS 13:52:07.913: debug : virDomainLookupByName:2154 : conn=0xe61390, name=i00cn1011 13:52:07.913: debug : remoteIO:9886 : Do proc=23 serial=3 length=44 wait=(nil) 13:52:07.913: debug : remoteIO:9961 : We have the buck 23 0xe671b0 0xe671b0 13:52:07.913: debug : remoteIODecodeMessageLength:9314 : Got length, now need 92 total (88 more) 13:52:07.913: debug : remoteIOEventLoop:9812 : Giving up the buck 23 0xe671b0 (nil) 13:52:07.913: debug : remoteIO:9990 : All done with our call 23 (nil) 0xe671b0 13:52:07.913: debug : virGetDomain:382 : New hash entry 0xe5da00 13:52:07.913: debug : virConnectOpenAuth:1498 : name=qemu+ssh://user@computer2/session, auth=0x7f3c96c6c7a0, flags=0 13:52:07.913: debug : do_open:1204 : name "qemu+ssh://user@computer2/session" to URI components: scheme qemu+ssh opaque (null) authority (null) server computer2 user user port 0 path /session 13:52:07.913: debug : do_open:1243 : trying driver 0 (Test) ... 13:52:07.913: debug : do_open:1249 : driver 0 Test returned DECLINED 13:52:07.913: debug : do_open:1243 : trying driver 1 (Xen) ... 13:52:07.913: debug : do_open:1249 : driver 1 Xen returned DECLINED 13:52:07.913: debug : do_open:1243 : trying driver 2 (OPENVZ) ... 13:52:07.913: debug : do_open:1249 : driver 2 OPENVZ returned DECLINED 13:52:07.913: debug : do_open:1243 : trying driver 3 (VBOX) ... 13:52:07.913: debug : do_open:1249 : driver 3 VBOX returned DECLINED 13:52:07.913: debug : do_open:1243 : trying driver 4 (remote) ... 13:52:07.913: debug : doRemoteOpen:564 : proceeding with name = qemu:///session 13:52:07.914: debug : virExecWithHook:712 : ssh -l user computer2 sh -c 'nc -q 2>&1 | grep -q "requires an argument";if [ $? -eq 0 ] ; then CMD="nc -q 0 -U /var/run/libvirt/libvirt-sock";else CMD="nc -U /var/run/libvirt/libvirt-sock";fi;eval "$CMD";' 13:52:07.914: debug : remoteIO:9886 : Do proc=66 serial=0 length=28 wait=(nil) 13:52:07.914: debug : remoteIO:9961 : We have the buck 66 0xeaabd0 0xeaabd0 13:52:08.006: debug : remoteIODecodeMessageLength:9314 : Got length, now need 36 total (32 more) 13:52:08.006: debug : remoteIOEventLoop:9812 : Giving up the buck 66 0xeaabd0 (nil) 13:52:08.006: debug : remoteIO:9990 : All done with our call 66 (nil) 0xeaabd0 13:52:08.006: debug : remoteIO:9886 : Do proc=1 serial=1 length=56 wait=(nil) 13:52:08.006: debug : remoteIO:9961 : We have the buck 1 0xeaabd0 0xeaabd0 13:52:08.007: debug : remoteIODecodeMessageLength:9314 : Got length, now need 28 total (24 more) 13:52:08.007: debug : remoteIOEventLoop:9812 : Giving up the buck 1 0xeaabd0 (nil) 13:52:08.007: debug : remoteIO:9990 : All done with our call 1 (nil) 0xeaabd0 13:52:08.007: debug : doRemoteOpen:941 : Adding Handler for remote events 13:52:08.007: debug : doRemoteOpen:948 : virEventAddHandle failed: No addHandleImpl defined. continuing without events. 13:52:08.007: debug : do_open:1249 : driver 4 remote returned SUCCESS 13:52:08.007: debug : do_open:1269 : network driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1269 : network driver 1 VBOX returned DECLINED 13:52:08.007: debug : do_open:1269 : network driver 2 remote returned SUCCESS 13:52:08.007: debug : do_open:1288 : interface driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1288 : interface driver 1 remote returned SUCCESS 13:52:08.007: debug : do_open:1308 : storage driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1308 : storage driver 1 VBOX returned DECLINED 13:52:08.007: debug : do_open:1308 : storage driver 2 remote returned SUCCESS 13:52:08.007: debug : do_open:1328 : node driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1328 : node driver 1 remote returned SUCCESS 13:52:08.007: debug : do_open:1355 : secret driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1355 : secret driver 1 remote returned SUCCESS 13:52:08.007: debug : do_open:1375 : nwfilter driver 0 Test returned DECLINED 13:52:08.007: debug : do_open:1375 : nwfilter driver 1 remote returned SUCCESS 13:52:08.007: debug : virDomainMigrate:3517 : domain=0xe5da00, dconn=0xe62b00, flags=65, dname=(null), uri=(null), bandwidth=0 13:52:08.008: debug : remoteIO:9886 : Do proc=60 serial=4 length=32 wait=(nil) 13:52:08.008: debug : remoteIO:9961 : We have the buck 60 0xeaac10 0xeaac10 13:52:08.008: debug : remoteIODecodeMessageLength:9314 : Got length, now need 60 total (56 more) 13:52:08.008: debug : remoteIOEventLoop:9812 : Giving up the buck 60 0xeaac10 (nil) 13:52:08.008: debug : remoteIO:9990 : All done with our call 60 (nil) 0xeaac10 13:52:08.008: debug : remoteIO:9886 : Do proc=60 serial=5 length=32 wait=(nil) 13:52:08.008: debug : remoteIO:9961 : We have the buck 60 0xeaac10 0xeaac10 13:52:08.008: debug : remoteIODecodeMessageLength:9314 : Got length, now need 60 total (56 more) 13:52:08.008: debug : remoteIOEventLoop:9812 : Giving up the buck 60 0xeaac10 (nil) 13:52:08.008: debug : remoteIO:9990 : All done with our call 60 (nil) 0xeaac10 13:52:08.008: debug : remoteIO:9886 : Do proc=60 serial=2 length=32 wait=(nil) 13:52:08.008: debug : remoteIO:9961 : We have the buck 60 0xeaac10 0xeaac10 13:52:08.009: debug : remoteIODecodeMessageLength:9314 : Got length, now need 32 total (28 more) 13:52:08.009: debug : remoteIOEventLoop:9812 : Giving up the buck 60 0xeaac10 (nil) 13:52:08.009: debug : remoteIO:9990 : All done with our call 60 (nil) 0xeaac10 13:52:08.009: debug : remoteIO:9886 : Do proc=14 serial=6 length=68 wait=(nil) 13:52:08.009: debug : remoteIO:9961 : We have the buck 14 0xeaac10 0xeaac10 13:52:08.009: debug : remoteIODecodeMessageLength:9314 : Got length, now need 2540 total (2536 more) 13:52:08.009: debug : remoteIOEventLoop:9812 : Giving up the buck 14 0xeaac10 (nil) 13:52:08.010: debug : remoteIO:9990 : All done with our call 14 (nil) 0xeaac10 13:52:08.010: debug : virDomainGetInfo:3017 : domain=0xe5da00, info=0x7fff102893e0 13:52:08.010: debug : remoteIO:9886 : Do proc=16 serial=7 length=64 wait=(nil) 13:52:08.010: debug : remoteIO:9961 : We have the buck 16 0xeaac10 0xeaac10 13:52:08.010: debug : remoteIODecodeMessageLength:9314 : Got length, now need 88 total (84 more) 13:52:08.010: debug : remoteIOEventLoop:9812 : Giving up the buck 16 0xeaac10 (nil) 13:52:08.010: debug : remoteIO:9990 : All done with our call 16 (nil) 0xeaac10 13:52:08.010: debug : remoteIO:9886 : Do proc=108 serial=3 length=2536 wait=(nil) 13:52:08.010: debug : remoteIO:9961 : We have the buck 108 0xeaac10 0xeaac10 13:52:08.291: debug : remoteIODecodeMessageLength:9314 : Got length, now need 68 total (64 more) 13:52:08.291: debug : remoteIOEventLoop:9812 : Giving up the buck 108 0xeaac10 (nil) 13:52:08.291: debug : remoteIO:9990 : All done with our call 108 (nil) 0xeaac10 13:52:08.291: debug : remoteIO:9886 : Do proc=62 serial=8 length=120 wait=(nil) 13:52:08.291: debug : remoteIO:9961 : We have the buck 62 0xeaac10 0xeaac10 13:52:38.000: debug : remoteIODecodeMessageLength:9314 : Got length, now need 208 total (204 more) 13:52:38.000: debug : remoteIOEventLoop:9812 : Giving up the buck 62 0xeaac10 (nil) 13:52:38.000: debug : remoteIO:9990 : All done with our call 62 (nil) 0xeaac10 13:52:38.000: debug : remoteIO:9886 : Do proc=109 serial=4 length=92 wait=(nil) 13:52:38.000: debug : remoteIO:9961 : We have the buck 109 0xeaac10 0xeaac10 13:52:38.211: debug : remoteIODecodeMessageLength:9314 : Got length, now need 120 total (116 more) 13:52:38.211: debug : remoteIOEventLoop:9812 : Giving up the buck 109 0xeaac10 (nil) 13:52:38.211: debug : remoteIO:9990 : All done with our call 109 (nil) 0xeaac10 13:52:38.211: debug : virConnectClose:1524 : conn=0xe62b00 13:52:38.211: debug : virUnrefConnect:294 : unref connection 0xe62b00 1 13:52:38.211: debug : remoteIO:9886 : Do proc=2 serial=5 length=28 wait=(nil) 13:52:38.211: debug : remoteIO:9961 : We have the buck 2 0xeaac10 0xeaac10 13:52:38.212: debug : remoteIODecodeMessageLength:9314 : Got length, now need 28 total (24 more) 13:52:38.212: debug : remoteIOEventLoop:9812 : Giving up the buck 2 0xeaac10 (nil) 13:52:38.212: debug : remoteIO:9990 : All done with our call 2 (nil) 0xeaac10 13:52:38.212: debug : virReleaseConnect:249 : release connection 0xe62b00 13:52:38.212: debug : virDomainFree:2242 : domain=0xe5da00 13:52:38.212: debug : virUnrefDomain:463 : unref domain 0xe5da00 i00cn1011 1 13:52:38.212: debug : virReleaseDomain:416 : release domain 0xe5da00 i00cn1011 4dd247bc-533a-db0d-f1e5-f1310169e62f 13:52:38.213: debug : virReleaseDomain:433 : unref connection 0xe61390 2 error: Timed out during operation: cannot acquire state change lock 13:52:38.213: debug : virConnectClose:1524 : conn=0xe61390 13:52:38.213: debug : virUnrefConnect:294 : unref connection 0xe61390 1 13:52:38.213: debug : remoteIO:9886 : Do proc=2 serial=9 length=28 wait=(nil) 13:52:38.213: debug : remoteIO:9961 : We have the buck 2 0xe671b0 0xe671b0 13:52:38.213: debug : remoteIODecodeMessageLength:9314 : Got length, now need 56 total (52 more) 13:52:38.213: debug : remoteIOEventLoop:9812 : Giving up the buck 2 0xe671b0 (nil) 13:52:38.213: debug : remoteIO:9990 : All done with our call 2 (nil) 0xe671b0 13:52:38.213: debug : virReleaseConnect:249 : release connection 0xe61390

2 3