What's the Pre-requisites for virt-manager

[Henry Zhang]

Hi all,

I am a little confused on the Pre-requisites for virt-manager, because I
am finding two:

1. at http://virt-manager.et.redhat.com/faq.html, under "What other
libraries are needed prior to installing "Virtual Machine Manager"?"

2. and find another one under "Pre-requisites" at
http://virt-manager.et.redhat.com/download.html

I am thinking 2 is a general one for all version of virt-manager, and 1
is exactly indicating the requirement before running latest virt-manger.
is it correct?

I am not in this alias, could you please reply me directly? thanks...

Regards,
Henry

[Daniel P. Berrange]

On Mon, Nov 06, 2006 at 01:22:58AM +0800, Henry Zhang wrote:
>  Hi all,
>  
>  I am a little confused on the Pre-requisites for virt-manager, because I
>  am finding two:
>  
>  1. at http://virt-manager.et.redhat.com/faq.html, under "What other
>  libraries are needed prior to installing "Virtual Machine Manager"?"
>  
>  2. and find another one under "Pre-requisites" at
>  http://virt-manager.et.redhat.com/download.html
>  
>  I am thinking 2 is a general one for all version of virt-manager, and 1
>  is exactly indicating the requirement before running latest virt-manger.
>  is it correct? 
The list on the download.html page is more up2date / accurate - I'll fix
the list under the faq.html to match this.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Thanks, Dan.

so for "pygtk2 >= 1.99.12-6", it means 1.99.12 - 1.6?
And I can say if we want virt-manager to run, pygtk2 1.99.12 can be OK, 
right?

BTW, I found these 2 requirements are different, for example, I can't 
find Matplotlib in download.html. So could you mind giving me a total 
list, including Pre-requisites and its earlist version, on what we need 
to build and run virt-manager?

Thanks again....

Regards,
Henry

Daniel P. Berrange 写道:
>  On Mon, Nov 06, 2006 at 01:22:58AM +0800, Henry Zhang wrote:
>    
> > Hi all,
> >
> > I am a little confused on the Pre-requisites for virt-manager, because I
> > am finding two:
> >
> > 1. at http://virt-manager.et.redhat.com/faq.html, under "What other
> > libraries are needed prior to installing "Virtual Machine Manager"?"
> >
> > 2. and find another one under "Pre-requisites" at
> > http://virt-manager.et.redhat.com/download.html
> >
> > I am thinking 2 is a general one for all version of virt-manager, and 1
> > is exactly indicating the requirement before running latest virt-manger.
> > is it correct?
> >     
>
>  The list on the download.html page is more up2date / accurate - I'll fix
>  the list under the faq.html to match this.
>
>  Regards,
>  Dan.
>

[Daniel P. Berrange]

On Mon, Nov 06, 2006 at 10:51:21AM +0800, Henry Zhang wrote:
>  Thanks, Dan.
>  
>  so for "pygtk2 >= 1.99.12-6", it means 1.99.12 - 1.6?
>  And I can say if we want virt-manager to run, pygtk2 1.99.12 can be OK, 
>  right? 
These version numbers refer to the RPM versions - so 1.99.12-6 refers
to pygtk2 1.99.12, with RPM release number 6. So for non-RPM builds
just look at the first component - 1.99.12

>  BTW, I found these 2 requirements are different, for example, I
> can't 
>  find Matplotlib in download.html. So could you mind giving me a total 
>  list, including Pre-requisites and its earlist version, on what we need 
>  to build and run virt-manager? 
Again, the 'download.html' page is the most accurate - it does
not list matplotlib since we no longer have that as a requirement,
the faq.html page is outdated in this respect. The version numbers
documented are the earliest that I have personally tested & verified
against. It may well run fine against even earlier versions - I just
haven't had opportunity to verify - if you find it does work against
earlier versions of particular software let me know & i'll update
the docs.

>  Daniel P. Berrange ??????:
>  >On Mon, Nov 06, 2006 at 01:22:58AM +0800, Henry Zhang wrote:
>  >>
>  >>I am a little confused on the Pre-requisites for virt-manager, because I
>  >>am finding two:
>  >>
>  >>1. at http://virt-manager.et.redhat.com/faq.html, under "What other
>  >>libraries are needed prior to installing "Virtual Machine
> Manager"?"
>  >>
>  >>2. and find another one under "Pre-requisites" at
>  >>http://virt-manager.et.redhat.com/download.html
>  >>
>  >>I am thinking 2 is a general one for all version of virt-manager, and 1
>  >>is exactly indicating the requirement before running latest virt-manger.
>  >>is it correct?
>  >>    
>  >
>  >The list on the download.html page is more up2date / accurate - I'll fix
>  >the list under the faq.html to match this. 
Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Hi Daniel,

Here I have another question on virt-manager, as you write "an embedded 
VNC client viewer provides console access to each of the guest domains", 
my concern is where is the vnc server, who provide it, and start it?
Need we setup vnc? I looked through the process used to create guest, 
seems there is no any step for vnc...

Thanks,
Henry

Daniel P. Berrange 写道:
>  On Mon, Nov 06, 2006 at 10:51:21AM +0800, Henry Zhang wrote:
>    
> > Thanks, Dan.
> >
> > so for "pygtk2 >= 1.99.12-6", it means 1.99.12 - 1.6?
> > And I can say if we want virt-manager to run, pygtk2 1.99.12 can be OK, 
> > right?
> >     
>
>  These version numbers refer to the RPM versions - so 1.99.12-6 refers
>  to pygtk2 1.99.12, with RPM release number 6. So for non-RPM builds
>  just look at the first component - 1.99.12
>
>    
> > BTW, I found these 2 requirements are different, for example, I can't 
> > find Matplotlib in download.html. So could you mind giving me a total 
> > list, including Pre-requisites and its earlist version, on what we need 
> > to build and run virt-manager?
> >     
>
>  Again, the 'download.html' page is the most accurate - it does
>  not list matplotlib since we no longer have that as a requirement,
>  the faq.html page is outdated in this respect. The version numbers
>  documented are the earliest that I have personally tested & verified
>  against. It may well run fine against even earlier versions - I just
>  haven't had opportunity to verify - if you find it does work against
>  earlier versions of particular software let me know & i'll update
>  the docs.
>
>    
> > Daniel P. Berrange ??????:
> >     
> >> On Mon, Nov 06, 2006 at 01:22:58AM +0800, Henry Zhang wrote:
> >>       
> >>> I am a little confused on the Pre-requisites for virt-manager, because I
> >>> am finding two:
> >>>
> >>> 1. at http://virt-manager.et.redhat.com/faq.html, under "What other
> >>> libraries are needed prior to installing "Virtual Machine
> Manager"?"
> >>>
> >>> 2. and find another one under "Pre-requisites" at
> >>> http://virt-manager.et.redhat.com/download.html
> >>>
> >>> I am thinking 2 is a general one for all version of virt-manager, and 1
> >>> is exactly indicating the requirement before running latest virt-manger.
> >>> is it correct?
> >>>    
> >>>         
> >> The list on the download.html page is more up2date / accurate - I'll fix
> >> the list under the faq.html to match this.
> >>       
>
>  Regards,
>  Dan.
>

[Daniel P. Berrange]

On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
>  Hi Daniel,
>  
>  Here I have another question on virt-manager, as you write "an embedded 
>  VNC client viewer provides console access to each of the guest domains", 
>  my concern is where is the vnc server, who provide it, and start it?
>  Need we setup vnc? I looked through the process used to create guest, 
>  seems there is no any step for vnc... 
The VNC server depends on what type of domain is being run. For HVM guests
the VNC server is provided by the qemu-dm process assoicated with that
guest. For paravirt guests, VNC is only available if you have the paravirt
framebuffer patches applied to your xen tree - these are not in xen-unstable
yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
server. So in both case all you need to do is set 'vnc=1' in the guest
config file & XenD will ensure the VNC servers are started as required.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Excellent explanation, I see... you are expert. :)

Thanks,
Henry

Daniel P. Berrange 写道:
>  On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
>    
> > Hi Daniel,
> >
> > Here I have another question on virt-manager, as you write "an embedded 
> > VNC client viewer provides console access to each of the guest domains", 
> > my concern is where is the vnc server, who provide it, and start it?
> > Need we setup vnc? I looked through the process used to create guest, 
> > seems there is no any step for vnc...
> >     
>
>  The VNC server depends on what type of domain is being run. For HVM guests
>  the VNC server is provided by the qemu-dm process assoicated with that
>  guest. For paravirt guests, VNC is only available if you have the paravirt
>  framebuffer patches applied to your xen tree - these are not in xen-unstable
>  yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
>  server. So in both case all you need to do is set 'vnc=1' in the guest
>  config file & XenD will ensure the VNC servers are started as required.
>
>  Dan.
>

[Henry Zhang]

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?

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?


Thanks,
Henry

Daniel P. Berrange 写道:
>  On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
>    
> > Hi Daniel,
> >
> > Here I have another question on virt-manager, as you write "an embedded 
> > VNC client viewer provides console access to each of the guest domains", 
> > my concern is where is the vnc server, who provide it, and start it?
> > Need we setup vnc? I looked through the process used to create guest, 
> > seems there is no any step for vnc...
> >     
>
>  The VNC server depends on what type of domain is being run. For HVM guests
>  the VNC server is provided by the qemu-dm process assoicated with that
>  guest. For paravirt guests, VNC is only available if you have the paravirt
>  framebuffer patches applied to your xen tree - these are not in xen-unstable
>  yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
>  server. So in both case all you need to do is set 'vnc=1' in the guest
>  config file & XenD will ensure the VNC servers are started as required.
>
>  Dan.
>

[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. 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, the second one will use DBus to find
the first one & just make RPC calls to it. It also allows other applications
within the local X desktop to control various bits of its UI. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

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?
>   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.
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.

I have to understand all of these, because we have to decide if we need 
to support these feature, and if we need integrate Dbus.
it's important to us....
>  the second one will use DBus to find
>  the first one & just make RPC calls to it. It also allows other applications
>  within the local X desktop to control various bits of its UI. 
>
>  Regards,
>  Dan.
>

[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.

>  > 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.

>  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.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

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.
>

[Daniel P. Berrange]

On Fri, Nov 24, 2006 at 08:28:24PM +0800, Henry Zhang wrote:
>  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? 
Yes, it should be pretty straightforward for you to remove the DBus bits
completely - just remove the src/virtManager/remote.py file, and any referneces
to DBus in srv/virt-manager.py.in

FYI, though I assume (from your email address) you're trying to get this
working on Solaris ? DBus should work on Solaris already, and I'm told
that there is also already a port of HAL to Solaris. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

> > 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?
> >     
>
>  Yes, it should be pretty straightforward for you to remove the DBus bits
>  completely - just remove the src/virtManager/remote.py file, and any referneces
>  to DBus in srv/virt-manager.py.in
>
>  FYI, though I assume (from your email address) you're trying to get this
>  working on Solaris ? DBus should work on Solaris already, and I'm told
>  that there is also already a port of HAL to Solaris. 
>     
yeah, HAL/DBus have been in Solaris, but at some version, the porting 
work have not done..
>  Regards,
>  Dan.
>

[Henry Zhang]

Dan,
>  Yes, it should be pretty straightforward for you to remove the DBus
> bits
>  completely - just remove the src/virtManager/remote.py file, and any referneces
>  to DBus in srv/virt-manager.py.in
>     
I checked the codes in create.py, seems if we delete DBus/HAL, we will 
can't list cdrom volumes when user
 selects "New Virtual Machine...". I think it's a big issue if not 
support CD install for guest Domain,

And seems there is an applet named gnome-nv-applet, but I didn't find 
any infor from our virt-manager website,
should we list it in this webpage? and seems this applet is also using 
DBus to access virt-manager, so if I delete
DBus/HAL, seems this applet can't work eigher.

I know you are expert for this tool.Could you give any good idea for 
that? especially for CD install....

Thanks,
Henry

[Karel Zak]

On Wed, Nov 29, 2006 at 04:43:49PM +0800, Henry Zhang wrote:
>  Dan,
>  >Yes, it should be pretty straightforward for you to remove the DBus bits
>  >completely - just remove the src/virtManager/remote.py file, and any 
>  >referneces
>  >to DBus in srv/virt-manager.py.in
>  >  
>  I checked the codes in create.py, seems if we delete DBus/HAL, we will 
>  can't list cdrom volumes when user
>  selects "New Virtual Machine...". I think it's a big issue if not 
>  support CD install for guest Domain,
>  
>  And seems there is an applet named gnome-nv-applet, but I didn't find 
>  any infor from our virt-manager website, 
 http://people.redhat.com/kzak/gnome-applet-vm/

 Hehe, you're right -- Dan forgot add the link to his web site :-)

>  should we list it in this webpage? and seems this applet is also
> using 
>  DBus to access virt-manager, so if I delete
>  DBus/HAL, seems this applet can't work eigher. 
 The latest versions of the applet and virt-manager are able to
 collaborate without DBUS.

    Karel

-- 
 Karel Zak  <kzak(a)redhat.com&gt;

[Daniel P. Berrange]

On Wed, Nov 29, 2006 at 04:43:49PM +0800, Henry Zhang wrote:
>  Dan,
>  >Yes, it should be pretty straightforward for you to remove the DBus bits
>  >completely - just remove the src/virtManager/remote.py file, and any 
>  >referneces
>  >to DBus in srv/virt-manager.py.in
>  >  
>  I checked the codes in create.py, seems if we delete DBus/HAL, we will 
>  can't list cdrom volumes when user
>  selects "New Virtual Machine...". I think it's a big issue if not 
>  support CD install for guest Domain, 
Ahh yes, sorry I completely forgot that we use DBus to talk to HAL to
get a list of CDROM devices available on the host system. This allows
you to easy install an HVM fullyvirt guest using media inserted into
you host, rather than forcing you to copy the media into an ISO file
first.

>  And seems there is an applet named gnome-nv-applet, but I didn't
> find 
>  any infor from our virt-manager website,
>  should we list it in this webpage? and seems this applet is also using 
>  DBus to access virt-manager, so if I delete
>  DBus/HAL, seems this applet can't work eigher. 
The applet used to use DBus, but now uses command line args to launch
virt-manager.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Hi Dan,

Daniel P. Berrange 写道:
>  On Wed, Nov 29, 2006 at 04:43:49PM +0800, Henry Zhang wrote:
>    
> > Dan,
> >     
> >> Yes, it should be pretty straightforward for you to remove the DBus bits
> >> completely - just remove the src/virtManager/remote.py file, and any 
> >> referneces
> >> to DBus in srv/virt-manager.py.in
> >>  
> >>       
> > I checked the codes in create.py, seems if we delete DBus/HAL, we will 
> > can't list cdrom volumes when user
> > selects "New Virtual Machine...". I think it's a big issue if not 
> > support CD install for guest Domain,
> >     
>
>  Ahh yes, sorry I completely forgot that we use DBus to talk to HAL to
>  get a list of CDROM devices available on the host system. This allows
>  you to easy install an HVM fullyvirt guest using media inserted into
>  you host, rather than forcing you to copy the media into an ISO file
>  first.
>     
Yes, I think CD install is really very important feature, so do you have 
plan to add some codes,
so that virt-manager can work correctly for getting CDROM devices when 
without DBUS/HAL?
>    
> > And seems there is an applet named gnome-nv-applet, but I didn't find 
> > any infor from our virt-manager website,
> > should we list it in this webpage? and seems this applet is also using 
> > DBus to access virt-manager, so if I delete
> > DBus/HAL, seems this applet can't work eigher.
> >     
>
>  The applet used to use DBus, but now uses command line args to launch
>  virt-manager.
>
>  Regards,
>  Dan.
>

[Daniel P. Berrange]

On Sat, Dec 02, 2006 at 03:48:46PM +0800, Henry Zhang wrote:
>  Hi Dan,
>  
>  Daniel P. Berrange ??????:
>  >On Wed, Nov 29, 2006 at 04:43:49PM +0800, Henry Zhang wrote:
>  >  
>  >>Dan,
>  >>    
>  >>>Yes, it should be pretty straightforward for you to remove the DBus bits
>  >>>completely - just remove the src/virtManager/remote.py file, and any 
>  >>>referneces
>  >>>to DBus in srv/virt-manager.py.in
>  >>> 
>  >>>      
>  >>I checked the codes in create.py, seems if we delete DBus/HAL, we will 
>  >>can't list cdrom volumes when user
>  >>selects "New Virtual Machine...". I think it's a big issue if not 
>  >>support CD install for guest Domain,
>  >>    
>  >
>  >Ahh yes, sorry I completely forgot that we use DBus to talk to HAL to
>  >get a list of CDROM devices available on the host system. This allows
>  >you to easy install an HVM fullyvirt guest using media inserted into
>  >you host, rather than forcing you to copy the media into an ISO file
>  >first.
>  >  
>  Yes, I think CD install is really very important feature, so do you have 
>  plan to add some codes,
>  so that virt-manager can work correctly for getting CDROM devices when 
>  without DBUS/HAL? 
No, if anything I think we'll increase the use of DBus. It is really now
a core part of the open source desktop API set, being used by both GNOME
and KDE alike, and for core system services like HAL, Bluetooth, etc.

Rgards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Thanks, Dan,
So I will try to add some codes for this issue...

Regards,
Henry

Daniel P. Berrange 写道:
>  On Sat, Dec 02, 2006 at 03:48:46PM +0800, Henry Zhang wrote:
>    
> > Hi Dan,
> >
> > Daniel P. Berrange ??????:
> >     
> >> On Wed, Nov 29, 2006 at 04:43:49PM +0800, Henry Zhang wrote:
> >>  
> >>       
> >>> Dan,
> >>>    
> >>>         
> >>>> Yes, it should be pretty straightforward for you to remove the DBus bits
> >>>> completely - just remove the src/virtManager/remote.py file, and any 
> >>>> referneces
> >>>> to DBus in srv/virt-manager.py.in
> >>>>
> >>>>      
> >>>>           
> >>> I checked the codes in create.py, seems if we delete DBus/HAL, we will 
> >>> can't list cdrom volumes when user
> >>> selects "New Virtual Machine...". I think it's a big issue if
> not 
> >>> support CD install for guest Domain,
> >>>    
> >>>         
> >> Ahh yes, sorry I completely forgot that we use DBus to talk to HAL to
> >> get a list of CDROM devices available on the host system. This allows
> >> you to easy install an HVM fullyvirt guest using media inserted into
> >> you host, rather than forcing you to copy the media into an ISO file
> >> first.
> >>  
> >>       
> > Yes, I think CD install is really very important feature, so do you have 
> > plan to add some codes,
> > so that virt-manager can work correctly for getting CDROM devices when 
> > without DBUS/HAL?
> >     
>
>  No, if anything I think we'll increase the use of DBus. It is really now
>  a core part of the open source desktop API set, being used by both GNOME
>  and KDE alike, and for core system services like HAL, Bluetooth, etc.
>
>  Rgards,
>  Dan.
>

[Henry Zhang]

hi Dan, I think it over, and seems more concern, see below,

Daniel P. Berrange 写道:
>  On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
>    
> > Hi Daniel,
> >
> > Here I have another question on virt-manager, as you write "an embedded 
> > VNC client viewer provides console access to each of the guest domains", 
> > my concern is where is the vnc server, who provide it, and start it?
> > Need we setup vnc? I looked through the process used to create guest, 
> > seems there is no any step for vnc...
> >     
>
>  The VNC server depends on what type of domain is being run. For HVM guests
>  the VNC server is provided by the qemu-dm process assoicated with that
>  guest. For paravirt guests, VNC is only available if you have the paravirt
>  framebuffer patches applied to your xen tree - these are not in xen-unstable
>  yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
>  server.  
due to vnc connection is required by vnc-viewer, vnc-viewer can present 
the graphical console,
because there is no paravirt framebuffer patches applied to 
xen-unstable, so virt-manager can't work
with xen-unstable for paravirt guests, because we can't get the 
graphical console run. is it right?

xen-unstable should be the latest version of Xen, if it has no paravirt 
framebuffer patches, maybe xen-stable
should have no either? and if so, we may say virt-manager not support 
paravirt at the moment?
>  So in both case all you need to do is set 'vnc=1' in the
> guest
>  config file & XenD will ensure the VNC servers are started as required.
>
>  Dan.
>

[Daniel P. Berrange]

On Fri, Nov 24, 2006 at 11:30:54AM +0800, Henry Zhang wrote:
>  hi Dan, I think it over, and seems more concern, see below,
>  
>  Daniel P. Berrange ??????:
>  >On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
>  >  
>  >>Hi Daniel,
>  >>
>  >>Here I have another question on virt-manager, as you write "an embedded 
>  >>VNC client viewer provides console access to each of the guest domains", 
>  >>my concern is where is the vnc server, who provide it, and start it?
>  >>Need we setup vnc? I looked through the process used to create guest, 
>  >>seems there is no any step for vnc...
>  >>    
>  >
>  >The VNC server depends on what type of domain is being run. For HVM guests
>  >the VNC server is provided by the qemu-dm process assoicated with that
>  >guest. For paravirt guests, VNC is only available if you have the paravirt
>  >framebuffer patches applied to your xen tree - these are not in 
>  >xen-unstable
>  >yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
>  >server. 
>  due to vnc connection is required by vnc-viewer, vnc-viewer can present 
>  the graphical console,
>  because there is no paravirt framebuffer patches applied to 
>  xen-unstable, so virt-manager can't work
>  with xen-unstable for paravirt guests, because we can't get the 
>  graphical console run. is it right? 
That is correct - the paravirt framebuffer patches are no yet in the
xen-unstable tree. In Fedora kernels we apply them as a patch ourselves
since it was important to have graphical console available for both PV
and FV guests in the same way. So any FC5, FC6 or RHEL-5 guest has the
PV framebuffer patches available already, even though they're not 
upstream

>  xen-unstable should be the latest version of Xen, if it has no
> paravirt 
>  framebuffer patches, maybe xen-stable
>  should have no either? and if so, we may say virt-manager not support 
>  paravirt at the moment? 
The PV framebuffer patches have been submitted several times & it looks
like they are very close to being merged upstream. Perhaps next couple
of weeks if all goes well.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Hi Dan,

 From Fedora site 
http://fedoraproject.org/wiki/Docs/Beats/Virtualization?highlight=%28xeng...

I find several information, I am sure if they are correct:

1, "Integrated graphical framebuffer. Both the GUI installer and the 
guest operating system's graphical environment can be accessed from 
virt-manager without the need for VNC."
As I remembered, you told me when we double-click any DomU, we will 
start a graphic console, this console just use virt-manmager embedded 
vnc-viewer to access DomU, so need vnc connection. Also I know when 
install a guest domain, there also will appear a vnc-viewer for install OS.
But from the above explanation, seems we never use vnc any more?

2,"CPU and memory management. The vCPUs and memory of active guest 
operating systems can be adjusted on the fly."
 From your website http://virt-manager.et.redhat.com/screenshots.html, I 
can see "Most of this dialog is currently non-functional. Compare with a 
scan of the design mockup" under "Virtual machine configuration", when I 
tried, seems it's true most of them can't work, so who is wrong?


Thanks,
Henry

Daniel P. Berrange 写道:
>  On Fri, Nov 24, 2006 at 11:30:54AM +0800, Henry Zhang wrote:
> > hi Dan, I think it over, and seems more concern, see below,
> >
> > Daniel P. Berrange ??????:
> >> On Wed, Nov 22, 2006 at 07:31:07PM +0800, Henry Zhang wrote:
> >>  
> >>> Hi Daniel,
> >>>
> >>> Here I have another question on virt-manager, as you write "an embedded
>
> >>> VNC client viewer provides console access to each of the guest domains",
>
> >>> my concern is where is the vnc server, who provide it, and start it?
> >>> Need we setup vnc? I looked through the process used to create guest, 
> >>> seems there is no any step for vnc...
> >>>    
> >> The VNC server depends on what type of domain is being run. For HVM guests
> >> the VNC server is provided by the qemu-dm process assoicated with that
> >> guest. For paravirt guests, VNC is only available if you have the paravirt
> >> framebuffer patches applied to your xen tree - these are not in 
> >> xen-unstable
> >> yet. In paravirt, XenD will launch a xen-vncfb process to provide the VNC
> >> server. 
> > due to vnc connection is required by vnc-viewer, vnc-viewer can present 
> > the graphical console,
> > because there is no paravirt framebuffer patches applied to 
> > xen-unstable, so virt-manager can't work
> > with xen-unstable for paravirt guests, because we can't get the 
> > graphical console run. is it right?
>  
>  That is correct - the paravirt framebuffer patches are no yet in the
>  xen-unstable tree. In Fedora kernels we apply them as a patch ourselves
>  since it was important to have graphical console available for both PV
>  and FV guests in the same way. So any FC5, FC6 or RHEL-5 guest has the
>  PV framebuffer patches available already, even though they're not 
>  upstream
>  
> > xen-unstable should be the latest version of Xen, if it has no paravirt 
> > framebuffer patches, maybe xen-stable
> > should have no either? and if so, we may say virt-manager not support 
> > paravirt at the moment?
>  
>  The PV framebuffer patches have been submitted several times & it looks
>  like they are very close to being merged upstream. Perhaps next couple
>  of weeks if all goes well.
>  
>  Regards,
>  Dan.

[Daniel P. Berrange]

On Mon, Dec 11, 2006 at 12:58:53AM +0800, Henry Zhang wrote:
>  Hi Dan,
>  
>  From Fedora site 
>  http://fedoraproject.org/wiki/Docs/Beats/Virtualization?highlight=%28xeng...
>  
>  I find several information, I am sure if they are correct:
>  
>  1, "Integrated graphical framebuffer. Both the GUI installer and the 
>  guest operating system's graphical environment can be accessed from 
>  virt-manager without the need for VNC."
>  As I remembered, you told me when we double-click any DomU, we will 
>  start a graphic console, this console just use virt-manmager embedded 
>  vnc-viewer to access DomU, so need vnc connection. Also I know when 
>  install a guest domain, there also will appear a vnc-viewer for install OS.
>  But from the above explanation, seems we never use vnc any more? 
What this means is that virt-manager implements the VNC protocol directly
itself, so there is no need for a separate vncviewer program. The VNC
code is all in the src/vncViewer directory.

>  2,"CPU and memory management. The vCPUs and memory of active
> guest 
>  operating systems can be adjusted on the fly."
>  From your website http://virt-manager.et.redhat.com/screenshots.html, I 
>  can see "Most of this dialog is currently non-functional. Compare with a 
>  scan of the design mockup" under "Virtual machine configuration", when I 
>  tried, seems it's true most of them can't work, so who is wrong? 
Actually the VCPU & memory adjustment is functional now - within certain
constraints. Paravirt guests can have memory & VCPUs adjusted. Fullyvirt
guests cannot have any adjustments. For guests which are not currently
running (ie inactive), memory, max-memory & VCPUs can be adjusted. Hotplug 
of disks & nics is not yet implemented for anything.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Henry Zhang]

Hi Dan,

Daniel P. Berrange 写道:
>  On Mon, Dec 11, 2006 at 12:58:53AM +0800, Henry Zhang wrote:
> > Hi Dan,
> >
> > From Fedora site 
> >
> http://fedoraproject.org/wiki/Docs/Beats/Virtualization?highlight=%28xeng...
> >
> > I find several information, I am sure if they are correct:
> >
> > 1, "Integrated graphical framebuffer. Both the GUI installer and the 
> > guest operating system's graphical environment can be accessed from 
> > virt-manager without the need for VNC."
> > As I remembered, you told me when we double-click any DomU, we will 
> > start a graphic console, this console just use virt-manmager embedded 
> > vnc-viewer to access DomU, so need vnc connection. Also I know when 
> > install a guest domain, there also will appear a vnc-viewer for install OS.
> > But from the above explanation, seems we never use vnc any more?
>  
>  What this means is that virt-manager implements the VNC protocol directly
>  itself, so there is no need for a separate vncviewer program. The VNC
>  code is all in the src/vncViewer directory. 
Ah, I see...
>  
> > 2,"CPU and memory management. The vCPUs and memory of active guest 
> > operating systems can be adjusted on the fly."
> > From your website http://virt-manager.et.redhat.com/screenshots.html, I 
> > can see "Most of this dialog is currently non-functional. Compare with a 
> > scan of the design mockup" under "Virtual machine configuration", when
> I 
> > tried, seems it's true most of them can't work, so who is wrong?
>  
>  Actually the VCPU & memory adjustment is functional now - within certain
>  constraints. Paravirt guests can have memory & VCPUs adjusted. Fullyvirt
>  guests cannot have any adjustments. For guests which are not currently
>  running (ie inactive), memory, max-memory & VCPUs can be adjusted. Hotplug 
>  of disks & nics is not yet implemented for anything. 
I hacked a virt-manager,
and it can run at Solaris now, I do a test, 
yes, you are right.

Seems here I have to add another question. :)
3, From http://fedoraproject.org/wiki/FedoraXenQuickstartFC6, I can see 
"Installation must be a network type. It is not possible to install from 
a local disk or CDROM. " is it true? As I remember virt-manager will get 
CDROM list for HVM install, can this feature run now? I have no this 
type of machine to test HVM.

BTW, when we create a new DomU, and not use virt-manager, what command 
line we can use? by now I only know virt-install, can xm or virsh create 
a DomU from zero?
>  
>  Regards,
>  Dan.