[virt-tools-list] rhel7 + virt-manager
Martin Kletzander
mkletzan at redhat.com
Mon May 12 04:59:18 UTC 2014
On Mon, May 12, 2014 at 11:00:26AM +0800, tzheng wrote:
>
>On 05/09/2014 09:58 PM, Sureshkumar Thirugnanasambandan wrote:
>>
>> ----- Original Message -----
>>> From: "Tingting Zheng" <tzheng at redhat.com>
>>> To: "Sureshkumar Thirugnanasambandan" <sthirugn at redhat.com>
>>> Cc: Virt-qe-list at redhat.com, virt-tools-list at redhat.com
>>> Sent: Thursday, May 8, 2014 11:12:00 PM
>>> Subject: Re: rhel7 + virt-manager
>>>
>>>
>>> ----- Original Message -----
>>> | From: "Sureshkumar Thirugnanasambandan" <sthirugn at redhat.com>
>>> | To: Virt-qe-list at redhat.com
>>> | Sent: Friday, May 9, 2014 3:30:17 AM
>>> | Subject: rhel7 + virt-manager
>>> |
>>> | I am not able to provision VMs using virt-manager in rhel 7. It opens the
>>> | virt-manager UI, but it is not letting me type or click anything to
>>> | provision the VM. Anybody encountered this problem before?
>>>
>>>
>>> Hi,Sureshkumar
>>> Do you launch virt-manager on your local host or use ssh -X then launch
>>> virt-manager on remote host?And would you pls paste your virt-manager
>>> vesrion and virt-manager --debug info?
>> Hi Tingting,
>> Thank you for your response.
>>
>> I do a ssh -X to the remote host and launch virt-manager from there.
>
>What about launching virt-manager from your local host?
>
>>
>> #rpm -qa | grep virt-manager
>> virt-manager-common-0.10.0-20.el7.noarch
>> virt-manager-0.10.0-20.el7.noarch
>
>I tried this version of virt-manager,it works well both on my local host
>and remote host through ssh -X.
>
>>
>> #virt-manager --debug
>> - please find the debug info here: http://pastebin.test.redhat.com/208122
>
>I see the error from the debug info,it is still some issue about dbus
>service,I am not sure whether it is the same issue with bug 1035368,cc'd
>martin for further checking.
>
> 1.
> 2014-05-09 09:55:26,732 (packageutils:130): Error searching for
> installed packages
> 2.
> Traceback (most recent call last):
> 3.
> File "/usr/share/virt-manager/virtManager/packageutils.py", line
> 123, in _do_async_search
> 4.
> cancellable)
> 5.
> File "/usr/share/virt-manager/virtManager/packageutils.py", line
> 152, in packagekit_search
> 6.
> tid = pk_control.CreateTransaction()
> 7.
> File "/usr/lib64/python2.7/site-packages/gi/overrides/Gio.py",
> line 171, in __call__
> 8.
> None)
> 9.
> File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113,
> in function
>10.
> return info.invoke(*args, **kwargs)
>11.
> GError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The
> name org.freedesktop.PackageKit was not provided by any .service files
>
This can happen and is definitely not a fatal problem, virt-manager
should be running even if this happens.
>
>
>>
>>> |
>>> | # virt-manager
>>> | ** (virt-manager:2325): WARNING **: Couldn't connect to accessibility bus:
>>> | Failed to connect to socket /tmp/dbus-ajPU0WKfED: Connection refused
>>> |
>>> |
>>>
This, however, I remember seeing already in some bug...
>>> I once tried to kill dbus dameon on remote machine manually,then ssh to that
>>> machine and try to launch virt-manager,I will get the similar error:
>>>
>>> Error starting Virtual Machine Manager: Failed to contact configuration
>>> server; some possible causes are that you need to enable TCP/IP networking
>>> for ORBit, or you have stale NFS locks due to a system crash. See
>>> http://projects.gnome.org/gconf/ for information. (Details - 1: Failed to
>>> get connection to session: Failed to connect to socket /tmp/dbus-LZlim7hIEG:
>>> Connection refused)
>>>
>>> Bug for reference:https://bugzilla.redhat.com/show_bug.cgi?id=1035368#c4
>> Sad that the bug is closed with no action.
>>
And yes, that's probably this one. The thing is that on one hand, we
can safely work without various dbus connections, but erroring out on
some connections like the one to the Accessibility bus is probably the
right choice as the root cause is your dbus is down even though it
should be running.
One more thing about this bug is that we had problems isolating the
issue the person came with (explaining more than one problem and than
saying that he doesn't have the setup available anymore).
I'm adding Giuseppe into Cc, since he's currently more familiar with
the codebase than I am.
The root cause of this problem might be solvable on different levels,
but definitely not virt-manager (or at least not virt-manager only).
I'm sure that when using systemd, dbus can be restarted if it's down,
etc. But if this is on the session bus, the connection parameters are
exposed by environment variables only, so I would say that by killing
that dbus, you (or any other user who does that) effectively spoiled
your setup. It's like killing abrt, syslog, cron, NetworkManager or
postfix, what do you expect then to happen? You won't have fully
working system either. And even if these services (apart from session
dbus) can be restarted, some part of your system won't be working
properly for a while. Or am I missing something truly elementary
here?
@Giuseppe: Would it be safe to assume that virt-manager can fallback
when connection to accessibility dbus fails?
Martin
>>> | --
>>> | Suresh Thirugnanasambandan| Sr. Quality Engineer | irc: sthirugn
>>> |
>>> |
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20140512/418223fb/attachment.sig>
More information about the virt-tools-list
mailing list