Re: [libvirt] Add new API for accessing remote guest text console
On Wed, Aug 18, 2010 at 12:53:41PM +0200, Soren Hansen wrote: On 17-08-2010 19:02, Daniel P. Berrange wrote: The 'virsh console' command has been an oddity that only works when run locally, as the same UID as the QEMU instance. This is because it directly opens /dev/pty/XXX. This introduces a formal API for accessing consoles that uses the virStreamPtr APIs. Now any app can open consoles anywhere it can connect to libvirt I don't (right now, at least) have any comments on the patches themselves, but I can't help but wonder what other wonderful improvements you've got in your pipeline. I spent at least a couple of hours on something like this a couple of weeks ago, but had I known that you were already doing it, I wouldn't have wasted my time. So, in an effort to not duplicate efforts, perhaps everyone who's working on something reasonably big (certainly stuff like this, but also smaller change sets) could put a list up somewhere for all to see? Perhaps such a list already exists and I just don't know about it? I'm in the process of working through all the RFE bugs against libvirt to put together a semi-formal 'roadmap' that we can publish. People could then put their names against items if they intend todo them. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Add new API for accessing remote guest text console
On 17-08-2010 19:02, Daniel P. Berrange wrote: The 'virsh console' command has been an oddity that only works when run locally, as the same UID as the QEMU instance. This is because it directly opens /dev/pty/XXX. This introduces a formal API for accessing consoles that uses the virStreamPtr APIs. Now any app can open consoles anywhere it can connect to libvirt I don't (right now, at least) have any comments on the patches themselves, but I can't help but wonder what other wonderful improvements you've got in your pipeline. I spent at least a couple of hours on something like this a couple of weeks ago, but had I known that you were already doing it, I wouldn't have wasted my time. So, in an effort to not duplicate efforts, perhaps everyone who's working on something reasonably big (certainly stuff like this, but also smaller change sets) could put a list up somewhere for all to see? Perhaps such a list already exists and I just don't know about it? -- Soren Hansen Ubuntu Developer http://www.ubuntu.com/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Add new API for accessing remote guest text console
The 'virsh console' command has been an oddity that only works when run locally, as the same UID as the QEMU instance. This is because it directly opens /dev/pty/XXX. This introduces a formal API for accessing consoles that uses the virStreamPtr APIs. Now any app can open consoles anywhere it can connect to libvirt -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Add new API for accessing remote guest text console
On Tue, 17 Aug 2010, Daniel P. Berrange wrote: The 'virsh console' command has been an oddity that only works when run locally, as the same UID as the QEMU instance. This is because it directly opens /dev/pty/XXX. This introduces a formal API for accessing consoles that uses the virStreamPtr APIs. Now any app can open consoles anywhere it can connect to libvirt This and the patches look LOVELY --- thank you We presently need to involve an admin level staffer to get onto the hosting box in question to be able to see the OOM, kernel, and other messages leaking out, and indeed to try to connect to a wedged instance. We had it happen just last week Getting network socket transport will solve a lot for us. Some authentication layer (PKI key mediated access comes to mind, similar to keyed SSH access), or ACL's to permit exposing specific consoles to specific end customers would close the loop -- Russ herrold -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
