9:24 a.m.
"Richard W.M. Jones" <rjones(a)redhat.com> writes:
On Thu, Dec 20, 2012 at 06:30:12PM +0800, Wanlong Gao wrote:
> On 12/20/2012 05:53 PM, Richard W.M. Jones wrote:
> > On Thu, Dec 20, 2012 at 05:30:03PM +0800, Wanlong Gao wrote:
> >> On 12/20/2012 05:08 PM, Richard W.M. Jones wrote:
> >>> On Thu, Dec 20, 2012 at 04:00:10PM +0800, Wanlong Gao wrote:
> >>>> Hi Rich,
> >>>>
> >>>> We just found that the libguestfs can't access the remote URI.
> >>>> When doing guestfs__add_drive_opts(), we always add files from
> >>>> local system, it's related the -c|--connect option.
> >>>>
> >>>> As I know, we are using local kernel to lunch the min-guest,
> >>>> and it's hard to attach remote disks to our local min-guest.
> >>>>
> >>>> Our test team found this problem by using following command,
> >>>>
> >>>> # virt-sysprep -c qemu+ssh://<host>/system -d domname
> >>>>
> >>>> Then, for example the path of remote disk is /work/rhel.img,
> >>>> but we are about to access the /work/rhel.img locally.
> >>>>
> >>>> So, IMHO, if we are about to not support the remote URI, we
> >>>> should give a error message first. But access local disks
> >>>> instead of remote disks are definitely wrong here.
> >>>>
> >>>> Maybe we also need document this.
> >>>>
> >>>> Any thoughts?
> >>>
> >>> John Eckersberg is working on implementing this for libguestfs 1.22.
> >>> Most of the libvirt support has been done already, but there is some
> >>> more libvirt and libguestfs work.
> >>>
> >>> As for reporting an error, it's difficult because libvirt
doesn't give
> >>> a simple way to find out if a URI is "remote" or not
(whatever
> >>> "remote" means). And even if libvirt did, it's not
necessarily true
> >>> that remote URIs wouldn't work, eg. if the user attached a LUN to
both
> >>> the remote and local machine.
> >>
> >> So, at this time, we should report a useful message to user but not just
> >> fail without any thing. Right?
> >
> > I don't know how you can report a useful message, since it's not
> > obvious if a libvirt URI is remote. eg. How about the URI
> > "qemu+ssh://foo/session" where the hostname of the local machine is
> > "foo.example.com"? Or the hostname is "bar.example.com" but
the local
> > DNS contains a PTR record "foo" -> "bar"?
>
> Oops, I don't have a good idea either.
> So, as John is doing this work, can you share the working progress and the roadmap
> so that we can help doing something?
[Adding John to the CC list]
Here is the plan I've been following:
https://www.redhat.com/archives/libvir-list/2011-September/msg01049.html
The rest of the thread is useful, but that summarizes it well. To quote
from there:
(1) An ugly new libvirt API that runs febootstrap-supermin-helper to
create the appliance.
I'm working on this part now. The idea is to take the <bootloader>
option that is presently used only by xen and make it work with qemu in
order to generate the appliance on the remote side, and then boot the
resulting kernel/initrd.
(2) Modify guestfs_add_domain to launch a transient domain using
virDomainCreate. (Forget about the live case for the moment).
This is already available with the libvirt attach method.
(3) A new libvirt API to open and forward a virtio-serial channel.
This seems generally a useful thing.
int virDomainOpenChannel(virStreamPtr, const char *channelid);
This is done, posted, and Dan has reviewed it. I believe it still needs
pushed by someone with commit access (not me). Here's the patches:
https://www.redhat.com/archives/libvir-list/2012-December/msg00820.html
(4) libguestfs somehow has to access a virStreamPtr. We can work
this
one out.
This should just be a matter of using the virStream API instead of unix
socket when using the libvirt attach method.