With the TLS socket, all data is encrypted on the wire. The TCP socket though
is still clear text. Fortunately some SASL authentication mechanism can
also supply encryption capabilities. This is called SSF in SASL terminology.
This patch mandates the use of an SSF capable SASL authentiction mech
This patch simply cleans up some legacy code which was choosing between
the QEMU driver protocol, and the generic remote protocol. There is no
ABI wire change there - just tidying up the structs we use internally.
a/qemud/protocol.c | 17 --
a/qemud/protocol.h | 39 -
This is the 2nd iteration of my remote authentication / SASL patches
previously provided here:
http://www.redhat.com/archives/libvir-list/2007-October/msg00131.html
In this iteration I've changed the wire protocol to give better compatability
with older libvirt clients. My previous version clien
On Thu, Nov 01, 2007 at 05:37:00PM +0900, Masayuki Sunou wrote:
> In message <[EMAIL PROTECTED]>
>"Re: [Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or
> earlier(BZ328841)"
>"Daniel Veillard <[EMAIL PROTECTED]>" wrote:
>
> Hi
>
> > >
> > > VirDomainDefineXML() fails
David Lutterkort wrote:
On Fri, 2007-10-26 at 09:08 -0400, Daniel Veillard wrote:
I can understand the need to make it easy for an user, I still don't
think this means those tuning informations need to be associated to the
domain definition, to me it is somehow orthogonal to the domain them
In message <[EMAIL PROTECTED]>
"Re: [Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or
earlier(BZ328841)"
"Daniel Veillard <[EMAIL PROTECTED]>" wrote:
Hi
> >
> > VirDomainDefineXML() fails, when HVM domain using CD-ROM is created
> > on Xen 3.0.3 or earlier.
> > -->BZ3
