[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [virt-tools-list] virt-manager remote connection woes



On Sun, Feb 20, 2011 at 03:38:01PM +0100, Malte Starostik wrote:
> SSH
> As stated above, it's been my choice for a while.  It's easy to set
> up, although I'm not too happy about pubkey auth for root on the
> target.  PolicyKit might come to help though (?). Anyway, when using
> SSH, the ssh child processes are never terminated unless and until
> manually killed.  100% reproducible.  Even after killing them, the
> corresponding nc process on the server keeps running.  This results
> in a DoS situation once libvirtd's client connection slots are
> exhausted.  This happens regardless of how the connection is
> (supposedly) closed: manual disconnect from virt-manager, regular or
> forceful termination of virt-manager, same outcome.  This has
> happened ever since I've started using the tool, maybe around 0.8.3
> (?).  Still happens with 0.8.6, guess I should've reported this as a
> bug by now.

Yes, please file a bug about this.

> SASL
> Given that there is a Kerberos setup at my disposal, I figured
> single sign on might be nice, so I tried.  Works great on a first
> glance!  But after varying amounts of time, virt-manager deadlocks.
> Sometimes it works for some hours, sometimes it locks up right after
> connecting.  Creating a new virtual machine is almost impossible,
> but does work after trying a few times - lockups happen at
> inpredictable stages of the wizard.  Just keeping virt-manager's
> main window open with an established connection will freeze it
> sooner or later.  FWIW, same applies to digest-md5 authentication.

And this.

> TLS
> Tried this just to make sure.  If you already have a PKI, this looks
> like a good choice, although I really don't like the hardcoded paths
> for the client stuff.  There was no /etc/pki dir on my machines, but
> if there was, file names like cacert.pem and client{cert,key}.pem
> sound rather ambiguous in a system- wide location.  It doesn't allow
> for per-user auth this way.  Anyway, assuming configurability on
> this part is going to come - the same deadlocks I've seen with SASL
> also happen with TLS :(

The deadlock issue sounds, as you say, like the above, so the bug you
filed about should cover it.

You can override at least some of the hard-coded paths by editing
'/etc/libvirt/libvirtd.conf'.

[...]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]