View previous topic :: View next topic |
Author |
Message |
dmoulding n00b
Joined: 03 Jun 2014 Posts: 26
|
Posted: Fri Dec 12, 2014 12:48 am Post subject: virt-manager broken : no attribute VIR_DOMAIN_BLOCKED |
|
|
An "emerge -aDNuv @world" today caused a rebuild of libvirt-python (1.2.9) on my system.
After that emerge, virt-manager could no longer run and was popping up a big ugly python error, the gist of which was: "'module' object has no attribute 'VIR_DOMAIN_BLOCKED'".
Some Googling led me to this libvirt bug: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=463733
So I checked the contents of libvirt.py, and -- sure enough -- there's no mention of VIR_DOMAIN_BLOCKED in there anywhere. Based on what was written in the above libvirt bug report, I tried remerging libvirt-python-1.2.9 with MAKEOPTS='-j1' in make.conf, in order to avoid doing a parallel build since the bug indicated there was a race condition in the makefile. That didn't help.
Finally, I tried masking libvirt-python-1.2.9, and then remerged libvirt-python, in order to get a different version of libvirt-python. It merged in 1.2.10 (~amd64) after adding ~amd64 keyword.
After the libvirt-python-1.2.10 was merged in I checked its libvirt.py and -- lo and behold -- there was a definition of VIR_DOMAIN_BLOCKED and a bunch of other definitions that were missing from it when I had 1.2.9 installed.
I had previously been using 1.2.9 successfully. It was only after it was forced to get rebuilt today that it broke. This whole thing just seems totally crazy. It seems maybe there still is a race condition in the libvirt-python build system, but ... why didn't MAKEOPTS='-j1' resolve it, and is it truly fixed in 1.2.10 or did I just get lucky?
Anybody else seeing this problem? |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Fri Dec 12, 2014 8:38 am Post subject: |
|
|
I just ran into this as well while upgrading to qemu-2 and libvirt-1.2.10-r1. I think this is a Gentoo bug based on my cursory Googling about this...
I just emerged libvirt-python-1.2.10 with virt-manager 1.1.0 and somehow it started working... There is something fishy going on here. Perhaps libvirt 1.2.10-r1 was marked stable but not libvirt-python-1.2.10? _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
dmoulding n00b
Joined: 03 Jun 2014 Posts: 26
|
Posted: Fri Dec 12, 2014 5:45 pm Post subject: |
|
|
eccerr0r wrote: | Perhaps libvirt 1.2.10-r1 was marked stable but not libvirt-python-1.2.10? |
Maybe. But libvirt.py in the 1.2.9 that got rebuilt for me was totally borked. It's not just that it's version didn't match libvirt. The file wasn't getting built correctly and was missing a lot of stuff that should have been there.
I guess it could be that for some reason libvirt-python doesn't build correctly when its version doesn't match libvirt. |
|
Back to top |
|
|
Moriah Advocate
Joined: 27 Mar 2004 Posts: 2365 Location: Kentucky
|
Posted: Sat Dec 13, 2014 3:54 pm Post subject: |
|
|
I previously posted about this problem at https://forums.gentoo.org/viewtopic-t-1006234-highlight-.html?sid=f70ada94b0d4ba88733f9eb37e163630 and was directed to this thread.
So I also emerged libvirt-python-1.2.10 with virt-manager 1.1.0, and it also started working for me, but it seems to be in software emulation mode, not native instruxction set mode, because it is so slow I can see the individual pixels being updated on the screen of my viewer. Surprisingly, the cpu is not heavily loaded. It has almost no load at all.
I was running libvirt and virt-manager on one machine, and also running a another machine where I was physically sitting. The X client windows of the virt-manager were being displayed on the machine I was physically sitting at, and I noticed that the load on the machine I was sitting at was pretty high. When I exited virt-manager, that load dropped back to normal, so this would indicate a lot of X packets were being transferred -- probably one per pixel being updated in the viewer of virt-manager. I found this somewhat strange.
So since I have never had qemu running in emulation mode before, where do I look to change it to native instruction set mode. BTW I am running on an intel I7, not an AMD cpu, if that makes any difference. _________________ The MyWord KJV Bible tool is at http://www.elilabs.com/~myword
Foghorn Leghorn is a Warner Bros. cartoon character. |
|
Back to top |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9679 Location: almost Mile High in the USA
|
Posted: Sat Dec 13, 2014 8:38 pm Post subject: |
|
|
dmoulding wrote: | Maybe. But libvirt.py in the 1.2.9 that got rebuilt for me was totally borked. It's not just that it's version didn't match libvirt. The file wasn't getting built correctly and was missing a lot of stuff that should have been there.
I guess it could be that for some reason libvirt-python doesn't build correctly when its version doesn't match libvirt. |
Seems to be true, I had another broken box that I subsequently re-merged libvirt-python to 1.2.10 but did not solve the issue. Then rebuilding libvirt 1.2.10-r1 fixed it.
Odd.
In any case the VMs appear to run full speed for me using KVM as expected, or at least I've been surprised that the speed of the VMs are not like 1/10th the speed of native.
I've mostly been using spice (bleah, I hate that name. SPICE is the circuit emulator!) and it seems to work ok for me. Most of my VM usage is on a Core2 machine, I haven't tried on my i5 or i7 in a while. _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
|
Moriah Advocate
Joined: 27 Mar 2004 Posts: 2365 Location: Kentucky
|
Posted: Sat Dec 13, 2014 10:00 pm Post subject: |
|
|
Well it is now working, and probably was before as well. When I ran virt-manager on the host so it displayed on the host's local display, everything works fine. When I run virt-manager by ssh-ing in from another machine on the lan, so the display windows of virt-manager are on the local display of the remote machine, then it is so slow updating the screen that it is useless.
Maybe I have never tried running on a remote display like that before, I don't know. I do it all the time with other programs, but maybe the vnc mode for virt-manager's display sends one packet per pixel, who knows.
Anyway, I can use my vm's again, and I discovered a weirdness about virt-manager's screen rendering.
I have run a tightvnc vncserver on the vm, and displayed the screen from it on another physical machine's local display, even over a slow internet connection, and that does work.
Strange. Not a bug as such, but a serious performance hit under certain scenarios. Probably worth looking into someday. But not today; I have lost enough time to this already. Back to real work. _________________ The MyWord KJV Bible tool is at http://www.elilabs.com/~myword
Foghorn Leghorn is a Warner Bros. cartoon character. |
|
Back to top |
|
|
normanshulman n00b
Joined: 15 Dec 2014 Posts: 4
|
Posted: Mon Dec 15, 2014 11:22 pm Post subject: |
|
|
Code: |
nshulman@nvshp:~
$ sudo emerge -1aqv ">libvirt-python-1.2.9"
[ebuild r U ] app-emulation/libvirt-1.2.11 [1.2.10-r2] USE="avahi caps libvirtd lvm macvtap nls policykit qemu udev vepa virt-network -audit -firewalld -fuse -iscsi -lxc -nfs -numa -openvz -parted -pcap -phyp -rbd -sasl (-selinux) -systemd -uml -virtualbox -wireshark-plugins -xen"
[ebuild U ] dev-python/libvirt-python-1.2.11 [1.2.9] USE="{-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4%"
[ebuild rR ] app-emulation/libvirt-glib-0.1.8 USE="introspection python vala" PYTHON_TARGETS="python2_7"
|
This solved the problem for me. |
|
Back to top |
|
|
|