headers
Daniel Hokka Zakrisson | 1 Nov 2007 02:11

Re: [RFC] Linux-VServer support

(Sorry about the resend, missed the list and DV the first time.)

Daniel P. Berrange wrote:
> On Wed, Oct 31, 2007 at 02:24:58PM +0100, Daniel Hokka Zakrisson wrote:
>> Daniel P. Berrange wrote:
>>> On Tue, Oct 30, 2007 at 04:28:59PM +0100, Daniel Hokka Zakrisson wrote:
>>>> This is an initial stab at adding Linux-VServer support to libvirt. 
>>>> There are still a couple of things missing, like scheduler support in 
>>>> the XML parsing, and proper network support.
>>> Great to see interest in adding more drivers ! I've not had time to look
>>> at your patch in great detail yet, but I'll give some more detailed
>>> feedback in the next day or so. My first comment though - why the 
>>> <xid>123</xid> field in the XML - the unique integer ID for a domain
>>> should really be in the 'id' attribute  <domain id='123'>. There are a
>>> couple of other small XML format consistency issues like that to check
>>> up on.
>> Yeah, the only reason I did it with a separate element was that I really 
>> don't know XPath, so I hadn't figured out how to get the id in that case.
>>
>>> NB, in most cases there is no need to implement network support in each
>>> driver. The libvirt networking APIs happen to be implemented in the QEMU
>>> driver codebase, but they're not really dependant on QEMU - the same
>>> functionality is shared across all drivers. If you connect to the Xen
>>> hypervisor, libvirt will auto-magically hook up the networking APIs to
>>> go via the QEMU driver. The same should work OK for VServer without
>>> you needing todo anything special.
>> Well, Linux-VServer is different from most (all?) other virtualization 
>> technologies in that we do IP isolation, rather than virtualizing the 
>> network stack. This means that guests are merely limited to a subset of 
>> the IP addresses assigned to the host, so there's no routing or bridging
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Hokka Zakrisson | 1 Nov 2007 03:09

Re: [RFC] Linux-VServer support

Daniel Veillard wrote:
> On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
>> Daniel Veillard wrote:
>>>  I looked at the code, that seems clean but I have a concern about the
>>> overall XML format. Could you paste a couple of examples. Also I think
>>> Linux-VServer and OpenVZ kind of configuration may end up with the same
>>> kind of limitations or differences, so I would like to try to harmonize
>>> both format when possible.
>> Currently, the XML format is really limited. Are there any docs on what 
>> should be there, or should I just look at the other drivers? As far as 
>> harmonizing with the OpenVZ driver, I'm fine with that, but it seems to 
>> be pretty limited and, to some degree at least, ugly.
> 
>   Harmonizing the XML formats shouldn't be that hard ...
> We discussed the OpenVZ format there
>   http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html
> and around there earlier:
>   http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html
> For network settings
>   http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
> 
>  <snip>

After looking at the various drivers, this is what I propose:

<domain type='vserver' id='2000'>
   <name>testvm</name>
   <memory>500000</memory>
   <scheduler fill_rate1='100' interval1='1000'>
     <cpu id='0' fill_rate1='0'/>
(Continue reading)

Permalink | Reply | 11 comments |
headers
Masayuki Sunou | 1 Nov 2007 09:37

Re: [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)

In message <20071031134628.GG8217 <at> redhat.com>
   "Re: [Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)"
   "Daniel Veillard <veillard <at> redhat.com>" wrote:

Hi

> > 
> > VirDomainDefineXML() fails, when HVM domain using CD-ROM is created
> > on Xen 3.0.3 or earlier.
> >  -->BZ328841(https://bugzilla.redhat.com/show_bug.cgi?id=328841)
> > 
> > One of attached patches (define.patch) fixes it.
> 
>   Could you please explain the patch, it changes the XML parsing and
> seems to change the S-Expr generation. How ? Providing examples or 
> explanations of how the patch works will help.
> 
This patch converts XML without the source element
which virt-install makes as follows.

<disk type='file' device='cdrom'>    convert
  <target dev='hdc'/>              ----------->  disk = [ ",hdc:cdrom,r" ]
  <readonly/>
</disk>

[Detail]
1. This does not fail when the source element doesn't exist
   and device is CD-ROM.
2. This adjusts the size of source to 0 in calculating buflen
   when the source element doesn't exist.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Fehlig | 1 Nov 2007 13:07
Picon
Favicon

Re: [PATCH] Xen: Support cpu_weight and cpu_cap for Xen.

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 themselves
>> and I would rather try to provide a good solution to the problem, than
>> try to imitate how Xen was doing that.
>>     
>
> Surely, users who set tuning parameters view them as part of their
> domain description.

I agree.  It appears the discussions around recent Linux-VServer patches 
includes tuning information in the XML description so I'm a little 
confused if this idea is being received positively or not.

I would like to avoid calling out to some other API for scheduling 
parameters at domU definition if at all possible.  Perhaps I've been 
away too long and this functionality already exists :-), but not seeing 
it in http://www.libvirt.org/format.html

Regards,
Jim
Permalink | Reply | 1 comment |
headers
Daniel Veillard | 1 Nov 2007 14:47
Picon
Favicon
Gravatar

Re: [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)

On Thu, Nov 01, 2007 at 05:37:00PM +0900, Masayuki Sunou wrote:
> In message <20071031134628.GG8217 <at> redhat.com>
>    "Re: [Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)"
>    "Daniel Veillard <veillard <at> redhat.com>" wrote:
> 
> Hi
> 
> > > 
> > > VirDomainDefineXML() fails, when HVM domain using CD-ROM is created
> > > on Xen 3.0.3 or earlier.
> > >  -->BZ328841(https://bugzilla.redhat.com/show_bug.cgi?id=328841)
> > > 
> > > One of attached patches (define.patch) fixes it.
> > 
> >   Could you please explain the patch, it changes the XML parsing and
> > seems to change the S-Expr generation. How ? Providing examples or 
> > explanations of how the patch works will help.
> > 
> This patch converts XML without the source element
> which virt-install makes as follows.
> 
> <disk type='file' device='cdrom'>    convert
>   <target dev='hdc'/>              ----------->  disk = [ ",hdc:cdrom,r" ]
>   <readonly/>
> </disk>
> 
> [Detail]
> 1. This does not fail when the source element doesn't exist
>    and device is CD-ROM.
> 2. This adjusts the size of source to 0 in calculating buflen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel P. Berrange | 2 Nov 2007 01:44
Picon
Favicon

PATCH: 0/4: Remote authentication support

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 clients would get a cryptic

   "unknown status 3"

if the server was mandating authentication. This is because I extended the
reply codes for RPC to include a specific 'auth required' code which old
clients are not expecting. The idea was that the new client would run the
REMOTE_PROC_OPEN rpc call & it would return a special NEED_AUTH code, the
client would then authenticate & redo the REMOTE_PROC_OPEN.

In the new way of doing things, instead of calling REMOTE_PROC_OPEN as the
first RPC, a new client will do  REMOTE_PROC_AUTH_LIST to query auth types
required by the server. It will choose an auth method (there may be several
to choose from), then complete the auth sequence. Only then will it try to
do the REMOTE_PROC_OPEN.  For compatability with older servers which do not
implement the REMOTE_PROC_AUTH_LIST rpc, it will catch & ignore the error
this may generate. Old clients which don't know to call REMOTE_PROC_AUTH_LIST
will get a proper virErrorPtr object returned from REMOTE_PROC_OPEN with
a clear 'authentication required' message.

The end result is that new client <-> new server has same level of functionality
as my previous patches, and  old client <-> new server gets friendly errors
reported (if server mandates auth - if no auth is enabled old client works
just fine).
(Continue reading)

Permalink | Reply | 12 comments |
headers
Daniel P. Berrange | 2 Nov 2007 01:48
Picon
Favicon

Re: PATCH: 1/4: Cleanup remote dispatch legacy code

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 --------------------------------
 a/qemud/protocol.x      |   40 ---------------------------------
 qemud/Makefile.am       |    5 ----
 qemud/internal.h        |    1 
 qemud/qemud.c           |   57 +++++++++++++++---------------------------------
 qemud/remote.c          |    2 -
 qemud/remote_protocol.h |    1 
 qemud/remote_protocol.x |    3 ++
 src/Makefile.am         |    1 
 10 files changed, 24 insertions(+), 142 deletions(-)

Dan.

diff -r ee2425c4d587 qemud/Makefile.am
--- a/qemud/Makefile.am	Wed Oct 17 11:35:03 2007 -0400
+++ b/qemud/Makefile.am	Wed Oct 17 15:02:48 2007 -0400
 <at>  <at>  -10,8 +10,7  <at>  <at>  conf_DATA = libvirtd.conf
 # Distribute the generated files so that rpcgen isn't required on the
 # target machine (although almost any Unix machine will have it).
 EXTRA_DIST = libvirtd.init.in libvirtd.sysconf default-network.xml \
-	protocol.x remote_protocol.x \
-	protocol.c protocol.h \
+	remote_protocol.x \
 	remote_protocol.c remote_protocol.h \
 	remote_generate_stubs.pl rpcgen_fix.pl \
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel P. Berrange | 2 Nov 2007 01:56
Picon
Favicon

Re: PATCH: 2/4: Auth infrastructure & basic SASL support

This patch hooks up the basic authentication RPC calls, and the specific
SASL implementation. The SASL impl can be enabled/disable via the configurre
script with --without-sasl / --with-sasl - it'll auto-enable it if it finds
the headers & libs OK.

The sample /etc/sasl2/libvirt.conf file enables the GSSAPI mechanism. This
requires a file /etc/libvirt/krb5.tab containing a service principle. On
some distros you need to set KRB5_KTNAME to point to this file when starting
the daemon, so our init script does that. Other distros, the 'keytab' config
param in /etc/sasl2/libvirt.conf is actually honoured.

With this patch you can successfully authentication client <-> server for
any authentication mechansim which doesn't need to prompt the user for
credentials. In effect this means it only works for GSSAPI/Kerberos. If
suitabl callbacks were supplied the same code would work for any other
auth mechanism, so we just need to agree on a callback API.


The way auth is controlled, is that if the 'auth' parameter is set on the
struct qemud_client object, *NO* rpc call will be processed except for the
REMOTE_PROC_AUTH_LIST, SASL_AUTH_INIT, SASL_AUTH_START & SASL_AUTH_STEP
calls. If SASL is not compiled in, the latter 3 will throw errors.

Only once authentication is complete, are the other calls allowed. It
currently hardcodes use of SASL on the TCP socket. The TLS & UNIX sockets
are unchanged.

The wire protocol for the SASL calls is changed so there is no longer a
fixed maximum string size for the auth negotiation packets.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel P. Berrange | 2 Nov 2007 02:09
Picon
Favicon

Re: PATCH: 3/4: Wire encryption with SASL

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 mechanism
on the TCP socket. This in effect restricts you to a choise between GSSAPI
and DIGEST-MD5 as your SASL auth methods (the latter is a user/password
based scheme). We also disallow anonymous & plaintext auth methods. If you
really want to run the TCP socket in clear text & with anonymous auth, simply
turn off SASL altogether. Since TLS already provides encryptiuon, if you run
SASL over the TLS socket, we don't place any restrictions on the choice of
SASL auth mechanism.

On the server side I have removed the 'direction' field of the client object.
This was only used on the TLS socket & was intended to track whether the
handshake process was waiting to receive or send. Rather than try to set
this in various places throughout the daemon code, we simply query the
neccessary direction at the one point where we register a FD event handle
with poll(). This makes the code clearer to follow & reduces the chance of
accidentally messing up the state.

The send & receive functions previously would call read vs gnutls_record_recv
and write vs gnutls_record_send depending on the type of socket. If there is
a SASL SSF layer enabled, we have to first pass the outgoing data through
the sasl_encode() API, and pass incoming data through sasl_decode(). So the
send/recive APIs have changed a little, to deal with this codec need and thus
there is also some more state being tracked per connection - we may have to
cache the output for sasl_decode for future calls depending on how much
data we need in short term.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel P. Berrange | 2 Nov 2007 02:15
Picon
Favicon

Re: PATCH: 4/4: Configuration & whitelisting users

This patch provides the ability to configure what authentication mechanism
is used on each socket - UNIX RW, UNIX RO, TCP, and TLS sockets - all can
have independant settings. By default the UNIX & TLS sockets have no auth,
and the TCP socket has SASL auth enabled. The /etc/libvirt/libvirtd.conf
file lets you override these options.

There is also a new  sasl_allowed_username_list = ["admin"]  config
param to let you whitelist the users you want to allow.  This supports
use of wildcards. The username is dependnat on the SASL auth mechanism.
For DIGEST-MD5 it will be plain usernames, for Kerberos it will be a
username + realm, eg  admin <at> EXAMPLE.COM

After discussion with Rich, I also remove the tls_allowed_ip_list for
whitelisting source IP addresses. This was a) not protecting us because
it was only checked after the TLS handshake - thus allowing trivial DOS
attack b) much easier to handle via tcp wrappers, or IPtables. c) only
ever checked for the TLS socket d) IP addresses are easily spoofed.

If summary, if you're using a real authentication mechanism, this is
only useful for protecting against DOS attacks & that's better done by
iptables.


 internal.h                   |    4 
 libvirtd.conf                |  139 ++++++++++++----
 qemud.c                      |  357 +++++++++++++++++++++----------------------
 remote.c                     |  290 +++++++++++++++++++++++++---------
 remote_dispatch_prototypes.h |  138 ++++++++--------
 remote_generate_stubs.pl     |    5 
 6 files changed, 572 insertions(+), 361 deletions(-)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane