[Libguestfs] Can't access remote URI

[John Eckersberg]

"Richard W.M. Jones" <rjones at 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.