* Itamar Heim <ih...@redhat.com> [2012-10-21 04:19]:

> >>>>>>>Maybe we can start simple and provide console access locally only.  
> >>>>>>>What sort of
> >>>>>>>functionality would the vdsm api need to provide to enable only local 
> >>>>>>>access to
> >>>>>>>the console?  Presumably, it would set up a connection and provide the 
> >>>>>>>user with
> >>>>>>>a port/pty to use to connect locally.  For now it would be "BYOSSH - 
> >>>>>>>bring your
> >>>>>>>own SSH" as clients would need to access the hosts with something like:
> >>>>>>>
> >>>>>>>ssh -t <host> "<connect command>"
> >>>>>>>
> >>>>>>>The above command could be wrapped in a vdsm-tool command.
> >>>>>>
> >>>>>>I think we have a patch that does local-only here but using virsh
> >>>>>>
> >>>>>>http://gerrit.ovirt.org/#/c/8041/
> >>>>>>
> >>>>>>I'd prefer to let the user tunnel that output over ssh if they need to.
> >>>>>
> >>>>>I haven't been following this thread all that closely, so perhaps this
> >>>>>idea has already been mentioned, but would the libvirt ssh transport
> >>>>>help with this situation, ie,
> >>>>>
> >>>>>virsh -c qemu+ssh://root@host/system console some_vm
> >>>>
> >>>>i hope this would work/be simple. some questions:
> >>>>1. can clients script with/over this method like they can with ssh?
> >>>
> >>>The serial console API does not do things like
> >>>
> >>>$ ssh root@bar 'hostname'
> >>>bar
> >>>
> >>>since it's just a stream containing the console i/o, but I'm not sure
> >>>that answers your question.  Can you give me an example of what kind
> >>>of script you're thinking of?
> >>>
> >>>>2. can we make it support tickets like we have for spice/vnc?
> >>>
> >>>The console API will use any authentication that the libvirtd on the
> >>>target will accept, so it could authenticate the same credentials as
> >>>vdsm.  console does require a read-write connection to libvirt.
> >>>
> >>>There's example python code in the libvirt git tree:
> >>>
> >>>http://libvirt.org/git/?p=libvirt.git;a=blob;f=examples/python/consolecallback.py
> >>
> >>I don't think giving end-users direct read/write access to libvirt
> >>is the way to go (even with libvirt having a permission model).
> >>we don't manage users/credentials at that level, only tickets.
> >
> >I agree with the additional creditials, I'd prefer not to have to manage
> >this.
> >
> >>the thing i like about the spice approach is it goes to qemu
> >>process, via channels we already have with clients (spice).
> >
> >We already have a device that works without additional clients or
> >channels, the pty on the host the VM runs.
> >
> >The only question left is how to provide remote access to this.  In the
> >short term, we don't need remoting to make use of it.  Having vdsm
> >invoke virsh console for a local vdsClient is sufficent to start with.
> >
> >For remoting, something we've been discussing is a
> >console_read/console_write API call which would be something that a
> >management application could consume and re-use some of those AJAX
> >web-console widgets.
> I thought the interesting use case for serial console was ability to
> script to it remotely, rather than a UI (which vnc/spice would give
> you anyway)?

Text-based serial console has many use-cases.  We can build whatever we
want on top of it, be that a UI or console/shells etc.

Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx

vdsm-devel mailing list

Reply via email to