[vdsm] [RFC]about the implement of text-based console
Dan Yasny
dyasny at redhat.com
Wed Nov 28 09:45:47 UTC 2012
----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>
> Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Sent: Tuesday, 27 November, 2012 7:45:27 PM
> Subject: Re: [vdsm] [RFC]about the implement of text-based console
>
> The best solution would of course be 3 (Or something similar that
> keeps the terminal state inside the VM memory so that migration
> works).
> Tunelling screen can do that but it requires having screen (or
> something similar) installed on the guest which is hard to do.
>
> But I think the more practical solution is 2 as it has semantics
> similar to VNC.
> Running a real ssh (ie. 1) is problematic because we have less
> control over the daemon and there are more vectors the user can try
> and use to break out of the sandbox.
> Further more, setting up sandboxes is a bit problematic ATM.
+1
>
> I don't really understand 5. What does those methods return the
> virtio dev path?
>
> ----- Original Message -----
> > From: "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>
> > To: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> > Sent: Tuesday, November 27, 2012 4:22:20 AM
> > Subject: Re: [vdsm] [RFC]about the implement of text-based console
> >
> > Hi all,
> >
> > For now in there is no agreement on the remote guest console
> > solution,
> > so I decide to do some investigation continue the discussion.
> >
> > Our goal
> > VM serial console remote access in CLI mode. That means the
> > client
> > runs without X environment.
> Do you mean like running qemu with -curses?
> >
> > There are several proposals.
> >
> > 1. Sandboxed sshd
> > VDSM runs a new host sshd instance in virtual machine/sandbox
> > and
> > redirects the virtio console to it.
> > 2. Third-party sshd
> > VDSM runs third-party sshd library/implementation and redirects
> > virtio console to it.
> > 3. Spice
> > Extend spice to support console and implement a client to be run
> > without GUI environment
> > 4. oVirt shell -> Engine -> libvirt
> > The user connects to Engine via oVirt CLI, then issues a
> > "serial-console" command, then Engine locates the host and connect
> > to
> > the guest console. Currently there is a workaround, it invokes
> > "virsh
> > -c
> > qemu+tls://host/qemu console vmid" from Engine side.
> > 5. VDSM console streaming API
> > VDSM exposes getConsoleReadStream() and getConsoleWriteStream()
> > via
> > XMLRPC binding. Then implement the related client in vdsClient and
> > Engine
> >
> >
> > Detailed discussion
> >
> > 1. Sandboxes
> > Solution 1 and 2 allow users connect to console using their
> > favorite
> > ssh
> > client. The login name is vmid, the password is set by
> > setVmTicket()
> > call of VDSM. The connection will be lost during migration. This is
> > similar to VNC in oVirt.
> >
> > I take a look at several sandbox technologies, including
> > libvirt-sandbox, lxc and selinux.
> > a) libvirt-sandbox boots a VM using host kernel and initramfs, then
> > passthru the host file system to the VM in read only mode. We can
> > also
> > add extra binding to the guest file system. It's very easy to use.
> > To
> > run shell in a VM, one can just issues
> >
> > virt-sandbox -c qemu:///session /bin/sh
> >
> > Then the VM will be ready in several seconds.
> > However it will trigger some selinux violations. Currently there is
> > no
> > official support for selinux policy configuration from this
> > project.
> > In
> > the project page this is put in the todo list.
> >
> > b) lxc utilize Linux container to run a process in sandbox. It
> > needs
> > to
> > be configured properly. I find in the package lxc-templates there
> > is
> > an
> > example configuration file for running sshd in lxc.
> >
> > c) sandbox command in the package policycoreutils-python makes use
> > of
> > selinux to run a process in sandbox, but there is no official or
> > example
> > policy files for sshd.
> >
> > In a word, for sandbox technologies, we have to configure the
> > policies/file system binding/network carefully and test the
> > compatibility with popular sshd implementations (openssh-server).
> > When
> > those sshd upgrade, the policy must be upgraded by us at the same
> > time.
> > Since the policies are not maintained by who implements sshd, this
> > is
> > a
> > burden for us.
> >
> > Work to do
> > Write and maintain the policies.
> > Find ways for auth callback and redirecting data to
> > openssh-server.
> >
> > pros
> > Re-use existing pieces and technologies (host sshd, sandbox).
> > User friendly, they can use existing ssh clients.
> > cons
> > Connection is lost in migration, this is not a big problem
> > because
> > 1)
> > VNC connection share the same problem, 2) the user can reconnect
> > manually.
> > It's not easy to maintain the sandbox policies/file system
> > binding/network for compatibility with sshd.
> >
> >
> > 2. Third-party sshd implementations
> > Almost the same as solution 1 but with better flexibility. VDSM can
> > import a third-party sshd library and let that library deal with
> > auth
> > and transport. VDSM just have to implement the data forwarding.
> > Many
> > people consider this is insecure but I think the ticket solution
> > for
> > VNC
> > is even not as secure as this. Currently most of us only trust
> > openssh-server and think the quality of third-party sshd is low. I
> > searched for a while and found twisted.conch from the popular
> > twisted
> > project. I'm not familiar with twisted.conch, but I still put it in
> > this
> > mail to collect opinions from potential twisted.conch experts.
> >
> > In a word, I prefer sandbox technologies to third-party sshd
> > implementations unless there is a implementation as good as
> > openssh-server.
> >
> > Work to do
> > Integrate twisted.conch into VDSM
> >
> > pros
> > Very flexible. If library provide auth callback to VDSM, then
> > VDSM
> > can just compares the login password to the VM ticket without
> > knowing
> > SSH detials.
> > cons
> > Third party implementations are not as secure and carefully
> > maintained as sshd in the host (probably openssh-server).
> >
> >
> > 3. Extend Spice to support console
> > Is it possible to implement a spice client can be run in pure text
> > mode
> > without GUI environment? If we extend the protocol to support
> > console
> > stream but the client must be run in GUI, it will be less useful.
> >
> > pros
> > No new VMs and server process, easy for maintenance.
> > cons
> > Must wait for Spice developers to commit the support.
> > Need special client program in CLI, the user may prefer existing
> > client program like ssh. It not a big problem because this feature
> > can
> > be put in to oVirt shell.
> >
> >
> > 4. oVirt shell -> Engine -> libvirtd
> > This is the current workaround described in
> >
> > http://wiki.ovirt.org/wiki/Features/Serial_Console_in_CLI#Currently_operational_workaround
> >
> > The design is good but I do not like Engine talking to libvirtd
> > directly, thus comes the VDSM console streaming API below.
> >
> > Work to do
> > Provide console streaming API from Engine to be invoked in oVirt
> > shell.
> > Implement the "serial-console" command in oVirt shell.
> >
> > pros
> > Support migration. Engine can reconnect to the guest
> > automatically
> > after migration while keeping the connection from oVirt shell.
> > Fit well in the current oVirt architecture: no new server
> > process
> > introduced, no new VM introduced, easy to maintain and manage.
> > cons
> > Engine talking to libvirtd directly breaks the encapsulation of
> > VDSM.
> > Users only can get the console stream from Engine, they can not
> > directly connect to the host as VNC and the above two sshd
> > solutions
> > do.
> >
> >
> > 5. VDSM console streaming API
> > Implement new APIs in VDSM to forward the raw data from console. It
> > exposes getConsoleReadStream() and getConsoleWriteStream() via
> > XMLRPC
> > binding. Then Engine can get the console data stream via API
> > instead
> > of
> > directly connecting to libvirtd. Other things will be the same as
> > solution 4.
> >
> > Work to do
> > Implement getConsoleReadStream() and getConsoleWriteStream() in
> > VDSM.
> > Provide console streaming API from Engine to be invoked in oVirt
> > shell.
> > Implement the "serial-console" command in oVirt shell.
> > Optional: Implement a client program in vdsClient to consume the
> > stream API.
> >
> > pros
> > Same as solution 4
> > cons
> > We can not allow ordinary user directly connect to VDSM and
> > invoke
> > the stream API, because there is no ACL in VDSM, once a client cert
> > is
> > setup for the ordinary user, he can call all the APIs in VDSM and
> > get
> > total control. So the ordinary user can only get the stream from
> > Engine,
> > and we leave Engine to do the ACL.
> >
> > I like solution 4 best.
> >
> > --
> > Thanks and best regards!
> >
> > Zhou Zheng Sheng / 周征晟
> > E-mail: zhshzhou at linux.vnet.ibm.com
> > Telephone: 86-10-82454397
> >
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
More information about the vdsm-devel
mailing list