On Fri, Oct 12, 2012 at 05:01:04PM +0200, Olaf Hering wrote:
> On Fri, Oct 12, Richard W.M. Jones wrote:
>
> > On Fri, Oct 12, 2012 at 04:20:50PM +0200, Olaf Hering wrote:
> > > On Wed, Oct 10, Richard W.M. Jones wrote:
> > >
> > > > libguestfs use of libvirt is a bit of a mess at the moment, since we
> > > > end up opening two connections if you use the -d option ... this is
> > > > something I'm intending to fix.
> > > >
> > > > Nevertheless, it should be using NULL everywhere, so depending on
> > > > whether you run it as root or not, it will use qemu:///system
> > > > or qemu:///session.
> > > >
> > > > It's somewhere on the to-do list to:
> > > >
> > > > (1) Fix the utilities so they only need to open one connection
> > > > (this will matter in the remote case).
> > > >
> > > > (2) Support authentication in libvirt by mapping libvirt auth
> > > > callbacks to libguestfs events.
> > >
> > > Is this the reason why the first command fails, but the others work ok
> > > for me?
> > >
> > > virt-filesystems -v -c qemu+ssh:///system -d sles11sp2 --all --long
> > >
> > > virt-rescue -v -c qemu+ssh:///system -d opensuse12 -r
> > > virsh -c qemu+ssh:///system list --all
> >
> > virt-rescue doesn't use the libvirt backend. See:
>
> It gets the list of configured devices from libvirt at least. The
> message it prints is clear about what you said:
>
> ...
> virt-rescue: warning: virt-rescue doesn't work with the libvirt backend
> at the moment. As a workaround, forcing attach-method = 'appliance'.
> ...
Right ... that comes down to the two connection thing (item (1) above).
What should happen is that the virt tool opens one connection to
libvirt, and then passes it along to libguestfs so it can use it to
create the transient appliance. In fact, this will not just be
desirable, but very necessary once we enable libvirt remote support,
or use libvirt authentication in any non-trivial manner.
In detail:
Up to 3 libvirt connections can be opened:
(i) virt-alignment-scan and virt-df have a way that you can scan all
domains, and in this case they get the list from libvirt by
opening a connection (align/domains.c, df/domains.c).
(ii) The -c/-d options call guestfs_add_domain, which opens a libvirt
connection in order to resolve the libvirt domain name into a
list of disks (src/libvirtdomain.c).
(iii) If the backend is libvirt, then we use libvirt to create the
appliance. This involves another libvirt connection which is
created entirely inside the libvirt backend
(src/launch-libvirt.c).
If we change things so the virt tool manages the libvirt connection,
the tool could pass it to a new API that libguestfs would be able to
use for guestfs_add_domain (ii) and/or the libvirt backend (iii), as
well as using it itself for listing domains (i).
There are three complicated bits to this, which is why I haven't just
gone ahead and implemented it yet:
(a) You might want to list domains from another (non-qemu) hypervisor,
but in general you'd always want to use qemu to create the
transient appliance. This argues for a way to have up to two
libvirt connections, but that becomes complex to implement.
(b) It's hard to pass virConnectPtr / virDomainPtr to libguestfs
functions, because there is no simple way to implement that
passing in any language binding other than C. Dan and I have
discussed this a bit but didn't come up with any good ideas.
(c) Existing backwards compat constraints: guestfs_add_domain takes an
optional 'libvirturi' parameter; the attach-method also has an
optional libvirt URI (ie. "libvirt:<URI>").
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
