Can't access remote URI
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 qemy+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? Thanks, Wanlong Gao
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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
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? Thanks, Wanlong Gao
Rich.
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"? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
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? Thanks, Wanlong Gao
Rich.
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] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
"Richard W.M. Jones" <rjones@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.
On Thu, Dec 20, 2012 at 09:53:17AM +0000, 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"?
In fact it is not merely a matter of whether the connection is remote or not. You can have the same problem of being unable to access the disk files if you're a unprivileged user connecting to the privileged libvirtd. Arguably you could just whitelist the URLs "qemu://session" (if libguestfs is running getuid() != 0) and "qemu:///system" (if libguetsfs is running getuid() == 0), and reject everything else until the tunnelling support is ready. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Another factor that may affect Fujitsu is that I'm hoping libguestfs 1.22 will be a short development cycle, and we'll have time to put remote support into RHEL 7 early (ie. 7.0, or 7.1 at latest). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
participants (4)
-
Daniel P. Berrange -
John Eckersberg -
Richard W.M. Jones -
Wanlong Gao