Re: [libvirt-users] Error creating a new vm
On 12/20/2010 07:57 AM, Jiri Denemark wrote: >> Here are the version numbers: >> >> virsh # version >> Compiled against library: libvir 0.6.3 >> Using library: libvir 0.6.3 >> Using API: QEMU 0.6.3 >> Running hypervisor: QEMU 0.9.0 >> >> Also here are the logs: >> >> # cat /var/log/libvirt/qemu/test01.log LC_ALL=C >> PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/ /usr/bin/qemu-system-x86_64 -S -M >> rhel5.4.0 -no-kqemu -m 512 -smp 1 -nographic -monitor pty -pidfile >> /var/run/libvirt/qemu//test01.pid -no-reboot -boot c -kernel >> /var/lib/libvirt/boot/virtinst-vmlinuz.wmv9KP -initrd >> /var/lib/libvirt/boot/virtinst-initrd.img.PBIGHX -append >> method=http://10.0.0.100/iso/centos-5.5/ console=ttyS0 >> ks=http://10.0.0.100/ks/ks-vm.cfg -hda /dev/vg_storage/test01 -net >> nic,macaddr=54:52:00:6f:8e:05,vlan=0 -net >> tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb >> Supported machines are: >> pc Standard PC (default) >> isapc ISA-only PC > > Ah, that is the problem. Your /usr/bin/qemu-system-x86_64 binary only supports > the above machine types but domain XML wants rhel5.4.0 machine type. Did you > install qemu from an unofficial package or something like that? Since normally > it supports rhel5.4.0 and the binary is called /usr/libexec/qemu-kvm. If you > really want to use the /usr/bin/qemu-system-x86_64 binary, you need to make > virt-install use "pc" machine type since by default it doesn't use any and > libvirt 0.6.3 selects rhel5.4.0 as a default (newer libvirt versions are more > clever in this). However, virt-install doesn't seem to have an option which > could be used for overriding machine type :-/ Just an FYI, upstream virt-install does have a --machine option - Cole ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] libvirt unavailable while a VM is in migration?
On Mon, Dec 20, 2010 at 02:14:42PM +0100, Jiri Denemark wrote: > Ouch, I wonder if that could be the reason... Could you just compile libvirt > yourself? I still had a box around where I was using a hand-compiled libvirt with the following version output: Compiled against library: libvir 0.8.5 Using library: libvir 0.8.5 Using API: QEMU 0.8.5 Running hypervisor: QEMU 0.12.5 I experimented on there, and found the same problem. What's more, the 0.8.5 version appears to have 'virsh list' freeze at the same spot as in the traceback I gave you for 0.8.6. I'm assuming therefore that the package conversion is not the issue here; I'd be happy to set up a hand-compiled 0.8.6 but that would take a little more time. > tries to authenticate to libvirtd. Could you run this second virsh list with > LIBVIRT_DEBUG environment variable set to 1 and attach the debug output? Also > please check the virsh is stuck in the same place. Hopefully the log will tell > us more. I have attached two 'virsh list' logs -- one where I just did 'virsh list' and one where I explicitly specified the URI ( 'virsh -c "qemu:///system" list'). Both appear to be stuck at the same spot. This spot is also the same on libvirt .8.5.0, which has generally identical output. Let me know what you think, and thanks again for helping me with this. --Igor cloud2:~# LIBVIRT_DEBUG=1 virsh list 08:08:08.217: 25725: debug : virInitialize:340 : register drivers 08:08:08.217: 25725: debug : virRegisterDriver:942 : registering Test as driver 0 08:08:08.217: 25725: debug : virRegisterNetworkDriver:748 : registering Test as network driver 0 08:08:08.217: 25725: debug : virRegisterInterfaceDriver:779 : registering Test as interface driver 0 08:08:08.217: 25725: debug : virRegisterStorageDriver:810 : registering Test as storage driver 0 08:08:08.217: 25725: debug : virRegisterDeviceMonitor:841 : registering Test as device driver 0 08:08:08.217: 25725: debug : virRegisterSecretDriver:872 : registering Test as secret driver 0 08:08:08.217: 25725: debug : virRegisterNWFilterDriver:903 : registering Test as network filter driver 0 08:08:08.217: 25725: debug : virRegisterDriver:942 : registering Xen as driver 1 08:08:08.217: 25725: debug : virRegisterDriver:942 : registering OPENVZ as driver 2 08:08:08.217: 25725: debug : virRegisterDriver:942 : registering PHYP as driver 3 08:08:08.217: 25725: debug : virRegisterStorageDriver:810 : registering PHYP as storage driver 1 08:08:08.217: 25725: debug : virRegisterNetworkDriver:748 : registering PHYP as network driver 1 08:08:08.218: 25725: debug : vboxRegister:122 : VBoxCGlueInit failed, using dummy driver 08:08:08.218: 25725: debug : virRegisterDriver:942 : registering VBOX as driver 4 08:08:08.218: 25725: debug : virRegisterNetworkDriver:748 : registering VBOX as network driver 2 08:08:08.218: 25725: debug : virRegisterStorageDriver:810 : registering VBOX as storage driver 2 08:08:08.218: 25725: debug : virRegisterDriver:942 : registering ESX as driver 5 08:08:08.218: 25725: debug : virRegisterInterfaceDriver:779 : registering ESX as interface driver 1 08:08:08.218: 25725: debug : virRegisterNetworkDriver:748 : registering ESX as network driver 3 08:08:08.218: 25725: debug : virRegisterStorageDriver:810 : registering ESX as storage driver 3 08:08:08.218: 25725: debug : virRegisterDeviceMonitor:841 : registering ESX as device driver 1 08:08:08.218: 25725: debug : virRegisterSecretDriver:872 : registering ESX as secret driver 1 08:08:08.218: 25725: debug : virRegisterNWFilterDriver:903 : registering ESX as network filter driver 1 08:08:08.218: 25725: debug : virRegisterDriver:942 : registering remote as driver 6 08:08:08.218: 25725: debug : virRegisterNetworkDriver:748 : registering remote as network driver 4 08:08:08.218: 25725: debug : virRegisterInterfaceDriver:779 : registering remote as interface driver 2 08:08:08.218: 25725: debug : virRegisterStorageDriver:810 : registering remote as storage driver 4 08:08:08.218: 25725: debug : virRegisterDeviceMonitor:841 : registering remote as device driver 2 08:08:08.218: 25725: debug : virRegisterSecretDriver:872 : registering remote as secret driver 2 08:08:08.218: 25725: debug : virRegisterNWFilterDriver:903 : registering remote as network filter driver 2 08:08:08.218: 25725: debug : virConnectOpenAuth:1513 : name=(null), auth=0x7ff2230dd340, flags=0 08:08:08.218: 25725: debug : do_open:1221 : no name, allowing driver auto-select 08:08:08.218: 25725: debug : do_open:1258 : trying driver 0 (Test) ... 08:08:08.218: 25725: debug : do_open:1264 : driver 0 Test returned DECLINED 08:08:08.218: 25725: debug : do_open:1258 : trying driver 1 (Xen) ... 08:08:08.218: 25725: debug : do_open:1264 : driver 1 Xen returned DECLINED 08:08:08.218: 25725: debug : do_open:1258 : trying driver 2 (OPENVZ) ... 08:08:08.218: 25725: debug : do_open:1264 : driver 2 OPENVZ returned DECLINED 08:08:08.218: 25725: debug : do_open:1258 : trying driver 3 (PHYP) ... 08:08:08.
Re: [libvirt-users] Error creating a new vm
On 20 Dec 2010, at 12:57, Jiri Denemark wrote: >> Here are the version numbers: >> >> virsh # version >> Compiled against library: libvir 0.6.3 >> Using library: libvir 0.6.3 >> Using API: QEMU 0.6.3 >> Running hypervisor: QEMU 0.9.0 >> >> Also here are the logs: >> >> # cat /var/log/libvirt/qemu/test01.log LC_ALL=C >> PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/ /usr/bin/qemu-system-x86_64 -S -M >> rhel5.4.0 -no-kqemu -m 512 -smp 1 -nographic -monitor pty -pidfile >> /var/run/libvirt/qemu//test01.pid -no-reboot -boot c -kernel >> /var/lib/libvirt/boot/virtinst-vmlinuz.wmv9KP -initrd >> /var/lib/libvirt/boot/virtinst-initrd.img.PBIGHX -append >> method=http://10.0.0.100/iso/centos-5.5/ console=ttyS0 >> ks=http://10.0.0.100/ks/ks-vm.cfg -hda /dev/vg_storage/test01 -net >> nic,macaddr=54:52:00:6f:8e:05,vlan=0 -net >> tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb >> Supported machines are: >> pc Standard PC (default) >> isapc ISA-only PC > > Ah, that is the problem. Your /usr/bin/qemu-system-x86_64 binary only supports > the above machine types but domain XML wants rhel5.4.0 machine type. Did you > install qemu from an unofficial package or something like that? Since normally > it supports rhel5.4.0 and the binary is called /usr/libexec/qemu-kvm. If you > really want to use the /usr/bin/qemu-system-x86_64 binary, you need to make > virt-install use "pc" machine type since by default it doesn't use any and > libvirt 0.6.3 selects rhel5.4.0 as a default (newer libvirt versions are more > clever in this). However, virt-install doesn't seem to have an option which > could be used for overriding machine type :-/ You would need to change the > type element in domain XML from >hvm > to >hvm > > The easiest fix is to use the /usr/libexec/qemu-kvm binary, which is provided > by kvm package. > > Jirka Hi Jirka, Thanks for your reply :) Well iv installed the default RPMS via Centos (5.5) How do I get around this? Isnt that kind of weird that you an install a rhel machine on what is essentially a rhel machine? Kind Regards Tony ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] libvirt unavailable while a VM is in migration?
> > So could you make sure you have debug info libvirt packages installed > > or in case you compile libvirt yourself that you compile with -g > > (should be there by default) and don't strip binaries. > > I am using the rpm packages distributed from the website, which I've > installed on my debian box using alien. Ouch, I wonder if that could be the reason... Could you just compile libvirt yourself? Personally, I wouldn't really trust such transformed package esp. considering the hacky steps you did and described in another email. > I've attached two gdb traces -- one for when a migration is just > running, and another where I've also got a blocked 'virsh list' from the > command line. It appears there's no difference between them (except in > the data counts in the thread actually doing the migration). > > I've also attached a trace for the 'virsh' process itself. Thanks, that was a good idea since according to it virsh is stuck while it tries to authenticate to libvirtd. Could you run this second virsh list with LIBVIRT_DEBUG environment variable set to 1 and attach the debug output? Also please check the virsh is stuck in the same place. Hopefully the log will tell us more. Jirka ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Error creating a new vm
> Here are the version numbers: > > virsh # version > Compiled against library: libvir 0.6.3 > Using library: libvir 0.6.3 > Using API: QEMU 0.6.3 > Running hypervisor: QEMU 0.9.0 > > Also here are the logs: > > # cat /var/log/libvirt/qemu/test01.log LC_ALL=C > PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/ /usr/bin/qemu-system-x86_64 -S -M > rhel5.4.0 -no-kqemu -m 512 -smp 1 -nographic -monitor pty -pidfile > /var/run/libvirt/qemu//test01.pid -no-reboot -boot c -kernel > /var/lib/libvirt/boot/virtinst-vmlinuz.wmv9KP -initrd > /var/lib/libvirt/boot/virtinst-initrd.img.PBIGHX -append > method=http://10.0.0.100/iso/centos-5.5/ console=ttyS0 > ks=http://10.0.0.100/ks/ks-vm.cfg -hda /dev/vg_storage/test01 -net > nic,macaddr=54:52:00:6f:8e:05,vlan=0 -net > tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb > Supported machines are: > pc Standard PC (default) > isapc ISA-only PC Ah, that is the problem. Your /usr/bin/qemu-system-x86_64 binary only supports the above machine types but domain XML wants rhel5.4.0 machine type. Did you install qemu from an unofficial package or something like that? Since normally it supports rhel5.4.0 and the binary is called /usr/libexec/qemu-kvm. If you really want to use the /usr/bin/qemu-system-x86_64 binary, you need to make virt-install use "pc" machine type since by default it doesn't use any and libvirt 0.6.3 selects rhel5.4.0 as a default (newer libvirt versions are more clever in this). However, virt-install doesn't seem to have an option which could be used for overriding machine type :-/ You would need to change the type element in domain XML from hvm to hvm The easiest fix is to use the /usr/libexec/qemu-kvm binary, which is provided by kvm package. Jirka ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Re: [libvirt-users] Error creating a new vm
On 20 Dec 2010, at 02:09, Osier Yang wrote:
> 于 2010年12月20日 04:48, Anthony Davis 写道:
>> Hi,
>>
>> I wonder if anyone can help me with this, I have been trying to get a vm up
>> and running for a while now and cant for the life of me work out why it isnt
>> working. The errors I get arnt very helpful and im at a loss as how to debug
>> this any further.
>>
>> Here is the command and output that I get...(Also nothing shows up with
>> virsh list --all after so its starting to install then dropping out)
>>
>> Hope someone can help. Thanks!
>>
>> [r...@server ~]# /usr/bin/virt-install -n test01 -r 512
>> --os-variant=virtio26 -l http://172.16.0.100/iso/centos-5.5/ --nographics
>> --noautoconsole --disk path=/dev/vg_storage/test01, bus=virtio -w bridge:br0
>> -x "console=ttyS0 ks=http://172.16.0.100/ks/ks-vm.cfg"; -d -v
> Hi, Anthony
>
> Which libvirt version do you use? If I'm right, it should be
> caused by a recent patch.
>
>/* wait for qemu process to to show up */
>if (ret == 0) {
>if (virFileReadPid(driver->stateDir, vm->def->name, &vm->pid)) {
>qemuReportError(VIR_ERR_INTERNAL_ERROR,
>_("Domain %s didn't show up\n"), vm->def->name);
>ret = -1;
>}
> #if 0
>} else if (ret == -2) {
>/*
> * XXX this is bogus. It isn't safe to set vm->pid = child
> * because the child no longer exists.
> */
>
>/* The virExec process that launches the daemon failed. Pending on
> * when it failed (we can't determine for sure), there may be
> * extra info in the domain log (if the hook failed for example).
> *
> * Pretend like things succeeded, and let 'WaitForMonitor' report
> * the log contents for us.
> */
>vm->pid = child;
>ret = 0;
> #endif
>}
>
> could you check your guest log, and also libvirtd log?
>
> /var/log/libvirt/qemu/$guest.log
> /var/log/messages
>
> Regards
> Osier
>
Hi Osier,
Here are the version numbers:
virsh # version
Compiled against library: libvir 0.6.3
Using library: libvir 0.6.3
Using API: QEMU 0.6.3
Running hypervisor: QEMU 0.9.0
Also here are the logs:
# cat /var/log/libvirt/qemu/test01.log LC_ALL=C
PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/ /usr/bin/qemu-system-x86_64 -S -M
rhel5.4.0 -no-kqemu -m 512 -smp 1 -nographic -monitor pty -pidfile
/var/run/libvirt/qemu//test01.pid -no-reboot -boot c -kernel
/var/lib/libvirt/boot/virtinst-vmlinuz.wmv9KP -initrd
/var/lib/libvirt/boot/virtinst-initrd.img.PBIGHX -append
method=http://10.0.0.100/iso/centos-5.5/ console=ttyS0
ks=http://10.0.0.100/ks/ks-vm.cfg -hda /dev/vg_storage/test01 -net
nic,macaddr=54:52:00:6f:8e:05,vlan=0 -net tap,fd=16,script=,vlan=0,ifname=vnet0
-serial pty -parallel none -usb
Supported machines are:
pc Standard PC (default)
isapc ISA-only PC
# cat /var/log/messages | grep "10:42"
Dec 20 10:42:11 ims-gl-lin01 libvirtd: 10:42:11.309: error : Domain not found:
no domain with matching name 'test01'
Dec 20 10:42:11 ims-gl-lin01 libvirtd: 10:42:11.329: error : Domain not found:
no domain with matching uuid '?ނ?P??'
Dec 20 10:42:11 ims-gl-lin01 libvirtd: 10:42:11.600: error : Domain not found:
no domain with matching name 'test01'
Dec 20 10:42:11 ims-gl-lin01 libvirtd: 10:42:11.611: warning : Unexpected exit
status '1', qemu probably failed
Dec 20 10:42:11 ims-gl-lin01 kernel: device vnet0 entered promiscuous mode
Dec 20 10:42:11 ims-gl-lin01 kernel: type=1700 audit(1292841731.617:22):
dev=vnet0 prom=256 old_prom=0 auid=4294967295 ses=4294967295
Dec 20 10:42:11 ims-gl-lin01 kernel: br0: port 2(vnet0) entering learning state
Dec 20 10:42:12 ims-gl-lin01 avahi-daemon[3118]: New relevant interface
vnet0.IPv6 for mDNS.
Dec 20 10:42:12 ims-gl-lin01 avahi-daemon[3118]: Joining mDNS multicast group
on interface vnet0.IPv6 with address fe80::fc52:ff:fe6f:8e05.
Dec 20 10:42:12 ims-gl-lin01 avahi-daemon[3118]: Registering new address record
for fe80::fc52:ff:fe6f:8e05 on vnet0.
Dec 20 10:42:21 ims-gl-lin01 libvirtd: 10:42:21.720: error : internal error
Domain test01 didn't show up
Dec 20 10:42:21 ims-gl-lin01 avahi-daemon[3118]: Interface vnet0.IPv6 no longer
relevant for mDNS.
Dec 20 10:42:21 ims-gl-lin01 avahi-daemon[3118]: Leaving mDNS multicast group
on interface vnet0.IPv6 with address fe80::fc52:ff:fe6f:8e05.
Dec 20 10:42:21 ims-gl-lin01 kernel: br0: port 2(vnet0) entering disabled state
Dec 20 10:42:21 ims-gl-lin01 avahi-daemon[3118]: Withdrawing address record for
fe80::fc52:ff:fe6f:8e05 on vnet0.
Dec 20 10:42:21 ims-gl-lin01 kernel: device vnet0 left promiscuous mode
Dec 20 10:42:21 ims-gl-lin01 kernel: type=1700 audit(1292841741.733:23):
dev=vnet0 prom=0 old_prom=256 auid=4294967295 ses=4294967295
Dec 20 10:42:21 ims-gl-lin01 kernel: br0: port 2(vnet0) entering disabled state
Hope you can help.
Kind Regads
Tony
___
libvirt-users mailing list
li
Re: [libvirt-users] libvirt unavailable while a VM is in migration?
On Mon, Dec 20, 2010 at 10:37:56AM +0100, Jiri Denemark wrote: > in your first email, you said you can't even run virsh list while migration is > running, right? yup -- when i start my migration using my python application, 'virsh list' no longer works from the command-line. i will try setting up a simple test-case i can use with 'virsh migrate' and let you know the results. > So could you make sure you have debug info libvirt packages installed > or in case you compile libvirt yourself that you compile with -g > (should be there by default) and don't strip binaries. I am using the rpm packages distributed from the website, which I've installed on my debian box using alien. I've attached two gdb traces -- one for when a migration is just running, and another where I've also got a blocked 'virsh list' from the command line. It appears there's no difference between them (except in the data counts in the thread actually doing the migration). I've also attached a trace for the 'virsh' process itself. Thanks for answering, hopefully we can get to the bottom of this. --Igor Thread 7 (Thread 0x7f6358f33710 (LWP 24325)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x7f635cb560e9 in _L_lock_953 () from /lib/libpthread.so.0 #2 0x7f635cb55f0b in __pthread_mutex_lock (mutex=0x7f6350015910) at pthread_mutex_lock.c:61 #3 0x0043d44d in qemuDriverLock (conn=0x7f635009b8f0) at qemu/qemu_driver.c:144 #4 qemudClose (conn=0x7f635009b8f0) at qemu/qemu_driver.c:4500 #5 0x7f636054a97b in virReleaseConnect (conn=0x7f635009b8f0) at datatypes.c:269 #6 0x7f636054b028 in virUnrefConnect (conn=0x7f635009b8f0) at datatypes.c:321 #7 0x7f63605525c8 in virConnectClose (conn=0x7f635009b8f0) at libvirt.c:1548 #8 0x0041941f in qemudFreeClient (opaque=0xc636f0) at libvirtd.c:2284 #9 qemudRunLoop (opaque=0xc636f0) at libvirtd.c:2358 #10 0x7f635cb538ba in start_thread (arg=) at pthread_create.c:300 #11 0x7f635c6b702d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x in ?? () Thread 6 (Thread 0x7f634effd710 (LWP 24476)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7f6360515886 in virCondWait (c=, m=) at util/threads-pthread.c:105 #2 0x0041aa15 in qemudWorker (data=0xc74ab0) at libvirtd.c:1565 #3 0x7f635cb538ba in start_thread (arg=) at pthread_create.c:300 #4 0x7f635c6b702d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Current language: auto The current source language is "auto; currently asm". Thread 5 (Thread 0x7f634e7fc710 (LWP 24478)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7f6360515886 in virCondWait (c=, m=) ---Type to continue, or q to quit--- at util/threads-pthread.c:105 #2 0x0041aa15 in qemudWorker (data=0xc74ac8) at libvirtd.c:1565 #3 0x7f635cb538ba in start_thread (arg=) at pthread_create.c:300 #4 0x7f635c6b702d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Thread 4 (Thread 0x7f634dffb710 (LWP 24489)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7f6360515886 in virCondWait (c=, m=) at util/threads-pthread.c:105 #2 0x0041aa15 in qemudWorker (data=0xc74ae0) at libvirtd.c:1565 #3 0x7f635cb538ba in start_thread (arg=) at pthread_create.c:300 #4 0x7f635c6b702d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () Thread 3 (Thread 0x7f634d7fa710 (LWP 24494)): #0 0x7f635cb5b0bd in read () at ../sysdeps/unix/syscall-template.S:82 #1 0x7f636051683e in read (fd=54, buf=0x13bddb0, count=32768) at /usr/include/bits/unistd.h:45 #2 saferead (fd=54, buf=0x13bddb0, count=32768) at util/util.c:95 #3 0x00447e03 in doTunnelSendAll (driver=0x7f6350015910, dconn=0x1202cf0, vm=0x7f63500197b0, dom_xml=, uri=0xc65980 "qemu+tcp://10.32.174.165/system", flags=23, dname=0x0, resource=0, dom=) at qemu/qemu_driver.c:11389 #4 doTunnelMigrate (driver=0x7f6350015910, dconn=0x1202cf0, vm=0x7f63500197b0, dom_xml=, uri=0xc65980 "qemu+tcp://10.32.174.165/system", flags=23, dname=0x0, resource=0, dom=) at qemu/qemu_driver.c:11604 #5 0x00448631 in doPeer2PeerMigrate (dom=0xc63970, cookie=, cookielen=, uri=0xc65980 "qemu+tcp://10.32.174.165/system", flags=23, dname=0x0, resource=0) at qemu/qemu_driver.c:11746 #6 qemudDomainMigratePerform (dom=0xc63970, cookie=, cookielen=, ---Type to continue, or q to quit--- uri=0xc65980 "qemu+tcp://10.32.174.165/system", flags=23, dname=0x0, resource=0) at qemu/qemu_driver.c:11816 #7 0x7f6360555b16 in virDomainMigratePerform (domain=0xc63970, cookie=0x0, cookielen=0, uri=0xc65980
Re: [libvirt-users] libvirt unavailable while a VM is in migration?
> I did some MORE testing. I obtain a domain object to a domain in two > separate python processes. I begin migrating the domain in one of these > processes, and then I call migrateSetMaxDowntime() on the domain in the > other process. Unsurprisingly, the call is blocked and does not return > until the migration finished. At that point it returned 0, but I have no > idea whether the call had any impact on the running migration. > > Even more confused about how this is supposed to work now, Hmm, the behavior you get is really weird. Most of libvirt APIs are synchronous so they only return after the operation has finished. If you need to do something else while the operation is running, you need a separate connection to libvirt (opened in a separate process or thread) which you can use for manipulating with other domains or, to some extent, even with the same domain. In the migration case, you can use the second connection to monitor migration progress (virDomainGetJobInfo), cancel the migration (virDomainAbortJob), turn live migration into non-live migration (virDomainSuspend), or setting maximum downtime (virDomainMigrateSetMaxDowntime). It's quite strange, that as you say you have two python processes and virDomainMigrateSetMaxDowntime doesn't finish until the migration itself finishes. I would suggest to start with a simple setup and try with virsh migrate and virsh migrate-setmaxdowntime started from separate terminals, but in your first email, you said you can't even run virsh list while migration is running, right? So could you make sure you have debug info libvirt packages installed or in case you compile libvirt yourself that you compile with -g (should be there by default) and don't strip binaries. Then try to get into the state, when a migration is running and virsh list (or virsh migrate-setmaxdowntime) from another terminal is blocked and attach gdb to libvirtd gdb -p $(pidof libvirtd) and type "thread apply all bt" in the gdb and send us the result. I'm curious why it doesn't work for you. Jirka ___ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
