[libvirt-users] Detecting Co-residency of VMs on KVM
by Shikhar Agarwal
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
13 years, 1 month
[libvirt-users] Detach devices using Libvirt+Xen
by Daniel Espling
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
13 years, 1 month
Re: [libvirt-users] [libvirt] Fail to import available VM image
by Laine Stump
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_s...
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.
13 years, 1 month
[libvirt-users] QEMU hook on restore
by Székelyi Szabolcs
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
13 years, 1 month
[libvirt-users] libvirtd restore error?
by lee
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
13 years, 1 month
[libvirt-users] virt-manager thru window's remote desktop
by Hisao Taguchi
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
13 years, 1 month
[libvirt-users] java binding
by Maurizio Paone
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
13 years, 1 month
[libvirt-users] Unable to collect VM metrics for ESX using libvirt
by sethu subbiah
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
13 years, 1 month
[libvirt-users] virsh migrate results in error: Timed out during operation: cannot acquire state change lock
by Nuno Sousa
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
13 years, 1 month
