Cole
Thanks for the response. I will try with --test-first-run option to see how it pans out.
Cheers
-Avaneendra
On Tue, Nov 17, 2015 at 1:54 PM, Cole Robinson <crobinso@xxxxxxxxxx> wrote:
On 11/17/2015 01:47 PM, Avaneendra Alugupalli wrote:
> Cole
> Thanks for your time. Will try to ask again. Sorry for my bad english :).
> Will try my best
> this time.
>
> I downloaded the code and tried to run the virt-manager.py of off eclipse
> Pydev IDE.
> Ran into some issues, not sure the order but ran
> glib-compile-schemas data/*schamas*
> ran "python setup.py -install"
>
> after that virt-manager sucessfully came up "with auto connected to lxc:///
> and qemu://system"
> *
> *
> Now I wanted to understand the code, ran the virt-manager in pdb -debugger.
> stepping into the config code found that the
> "/org/virt-manager/virt-manager/connections/uris"
> is already populated with " lxc:/// and qemu://system" value.
>
> but I see that this tuple in dconf DB is only updated by engine code. now
> wondering how
> does config is able to see the " lxc:/// and qemu://system" values.
>
If this was your first time running virt-manager, there is some first-run code
to try and determine a default connection, see engine.py:_add_default_conn as
a starting point.
That said, I don't know what could have caused the app to start up with both
qemu:///system _and_ lxc:/// in the connection list, it should only be one or
the other (or none, or an error message). You sure you definitely haven't run
virt-manager before?
FWIW you can test the first-run behavior again by using virt-manager --debug
--test-first-run, if you're just trying to figure out how it works
- Cole
>
> On Tue, Nov 17, 2015 at 1:37 PM, Cole Robinson <crobinso@xxxxxxxxxx
> <mailto:crobinso@xxxxxxxxxx>> wrote:
>
> On 11/17/2015 11:40 AM, Avaneendra Alugupalli wrote:
> > hi Cole
> > Thanks for the response.
> >>
> >
> >>The functions that add/remove/list the URIs in config.py are add_conn,
> >> remove_conn, list_conn_uris respectively. They are called from engine.py
> >
> > From the code in virt-manager.py main handler, I find that the
> > config object is getting created before the engine object?. Is that for the first
> > time when I run the virt-manager app. config sees default values of connections/
> > uris to none [] and then engine creates them. And even if the app is exited
> > we still have non default values ("qemu:///sysmtem" and "lxc://") in the dconf?.
> > perhaps not delete those values from dconf?.
> >
>
> Sorry, I'm not really following what you are saying. Can you describe the
> problem you are hitting, step by step, and exactly what you are trying to
> determine?
>
> Also, take a look at dconf-editor, it's a UI tool for exploring dconf values.
> Might explain what you are seeing.
>
> - Cole
>
> >
> > On Mon, Nov 16, 2015 at 8:09 PM, Cole Robinson <crobinso@xxxxxxxxxx <mailto:crobinso@xxxxxxxxxx>
> > <mailto:crobinso@xxxxxxxxxx <mailto:crobinso@xxxxxxxxxx>>> wrote:
> >
> > On 11/16/2015 02:17 PM, Avaneendra Alugupalli wrote:
> > > hi
> > > I am trying to understand the code for virt-manager and found
> that during the
> > > config object create, gets the connections / uris using the
> Gsettings API. and
> > > these are the entries in dconf database.
> > >
> > > forchild inself._settings.list_children():
> > > childschema =self._root +"."+child
> > > self._settingsmap[child] =Gio.Settings.new(childschema)
> > >
> > >
> > > returns connections/uris as "qemu:///system" and "lxc:///". From the
> > >
> > > I can see that data
> > >
> >
> <https://github.com/virt-manager/virt-manager/tree/master/data>/org.virt-manager.virt-manager.gschema.xml
> > > makes
> > > default entry for these fields. How ever am unable to track who is
> updating
> > > the connections/uris to "qemu:///system" and "lxc:///" strings.
> >
> > The functions that add/remove/list the URIs in config.py are add_conn,
> > remove_conn, list_conn_uris respectively. They are called from engine.py
> >
> > > Also is there any architecture/ design document to understand the
> code at very
> > > higher
> > > level?.
> >
> > No unfortunately :/
> >
> > - Cole
> >
> >
>
>
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
