Dan,
that's great, see comments below...
Daniel P. Berrange 写道:
On Fri, Nov 24, 2006 at 10:52:13AM +0800, Henry Zhang wrote:
Thanks Dan, please see comments below.. :)
Daniel P. Berrange ??????:
On Thu, Nov 23, 2006 at 07:54:24PM +0800, Henry Zhang wrote:
hi Daniel,
>From the webpage, I can see that dbus and gnome-python-desktop are
optional, but when our release engineer try to build, seems they are
not, so could you confirm me if we can build/run virt-manager correctly
without Dbus?
Ah, I should perhaps clarify that a little. The DBus python libraries
are required to be present, but you don't have to have DBus running.
So can I say: Dbus is necessary one for building virt-manager, while not
when running it?
The DBus python libraries *are* needed at runtime. If the DBus daemon isn't
present though, we catch the connection failure and disable that piece of
the virtmanager functionality on the fly.
thanks, I know what you mean,
now for us, the problem is we don't want to port Dbus/HAL, it means when
we build virt-manager there is no Dbus/HAL in our system, if we want to
succeed in building, I am thinking to delete all codes relative to Dbus,
I find they are almost in remote.py, and some code in makefile,
create.py and virt-manager.py.in, do you think it's ok?
If it fails to connect to the DBus daemon, the app will log a warning and
continue. The GNome Python Desktop stuff is competely optional - if you
don't have the python bindings installed it will simply disable the VNC
password saving altogether.
I carefully read the content in "Dbus Services", My understanding is
that Dbus in virt-manager is used to make other external application
call some core function, so that they can get display the window/dialog .
When Dbus is used?
"The remote control module provides the DBus service
<http://virt-manager.et.redhat.com/dbusservice.html> allowing various UI
functions to be controlled remotely.": My understanding for "remotely"
is to run virt-manager remotely, is it correct? so will dbus only used
when remotely? if some application in local machine, it may also use
Dbus to run some function?
Not quite - the intent with the DBus stuff is that if you run two copies
of virt-manager on the same machine,
For "two copies of virt-manager": my understanding is:
Case 1: when I login, and run %/usr/binvirt-manager, then when I run
%/usr/bin/virt-manager in the same machine again,
the second one is the copy of first one, and just use DBus/RPC to call.
Yes, the first copy you run of 'virt-manager' pops up the window directly.
The second concurrent copy will send a DBus message to the first, asking
it to popup a particular window, and then the second copy exits - since the
first copy is dealing with it now.
So it seems only when in one machine, Dbus is used, so why named remote
control and in remote.py?
My understanding is when second copy is running, if there is first one
is running, send Dbus message,
and in the end exit, so there is only one virt-manager running there,
but when I try in Fedaro 6, seems
I can run several virt-manager after I login. a little weird.. :)
Case2: When I login machine A, run %/usr/binvirt-manager, then remotely
access machine A through machine B,
and run %/usr/bin/virt-manager again, so in this case, the second one is
the copy of the first one, and use Dbus/RPC.
In most cases the DBus daemon is only available if you are logged into
a local X / GNOME desktop session. If you are ssh'ing into a machine
remotely it typically won't have DBus session available. So, when DBus
isn't available, many copies of virt-manager will be launched and have
no way to detect that another copy is already running.
When the DBus folks get the DBus connection automatically forwarding
over SSH, in the same way that X11 is forwarded, then the remote case
will work in same way as local case. I've no idea when that'll be
made to work though.
Regards,
Dan.
--
Fedora-xen mailing list
Fedora-xen@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-xen
