WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] New API Document and C Bindings

To: Gareth S Bestor <bestor@xxxxxxxxxx>
Subject: Re: [Xen-API] New API Document and C Bindings
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Thu, 14 Sep 2006 20:18:44 -0400
Cc: xen-api-bounces@xxxxxxxxxxxxxxxxxxx, Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 14 Sep 2006 17:19:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF80975B35.2A298B34-ON882571E9.007CB7DC-882571E9.007E1222@xxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

xen-api-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/14/2006 06:57:01 PM:

> Whilst I dont disagree that in Xen the Dom0 (and to be driver
> domains, stub domains, etc) have a lot of management characteristic
> in common with DomU's, in the fundamental DMTF System Virt model
> there is a clear distinction between the 'host' system - that which
> hands out resources/shares - and the 'virtual' or 'guest' systems -
> those whom consume these (virtualized) resources.
>
> Of course, that said, there is no particular reason that the Xen API
> and its objects must mirror this rather black-and-white distinction.
> And in the case of when we start dealing with lots of different
> 'flavors' of domains, there is certianly now a bigger grey area as
> to what are pure "guest domains" and what are "management domains".
> eg I would have a much harder time justifying Dom0 as unique once
> all these other mgmt related domains come into the picture... And
> once we can have DomUs essentially 'managing' other DomUs in a
> front-end/back-end manner everything goes out the window! :-)


In that case I would suggest introducing a privileged flag for the VM classes. Maybe that ends up being a distinguishing factor between VMs like dom-0, driver domains and other guests.

   Stefan

>
> So perhaps for Xen at least, maybe it does not (or soon will not)
> make sense to distinguish between the two in the API, and instead
> let the CIM stuff sitting on top what whatever black-and-white
> distinctions are required to satisfy the formal DMTF model.
>
> interesting... good points... :-)
>
> - Gareth
>
> Dr. Gareth S. Bestor
> IBM Linux Technology Center
> M/S DES2-01
> 15300 SW Koll Parkway, Beaverton, OR 97006
> 503-578-3186, T/L 775-3186, Fax 503-578-3186
>
> [image removed] "Daniel P. Berrange" <berrange@xxxxxxxxxx>
>

>
> "Daniel P. Berrange" <berrange@xxxxxxxxxx>
> Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx

> 09/14/06 02:47 PM
>
> Please respond to
> "Daniel P. Berrange" <berrange@xxxxxxxxxx>

>
> [image removed]

> To
>
> [image removed]
> Jim Fehlig <jfehlig@xxxxxxxxxx>

>
> [image removed]

> cc
>
> [image removed]
> Xen-API <xen-api@xxxxxxxxxxxxxxxxxxx>

>
> [image removed]

> Subject
>
> [image removed]
> Re: [Xen-API] New API Document and C Bindings

>
> [image removed]

>
> [image removed]

>
>
> On Thu, Sep 14, 2006 at 03:36:35PM -0600, Jim Fehlig wrote:
> > Ewan Mellor wrote:
> > >On Tue, Sep 12, 2006 at 07:16:40PM -0400, Stefan Berger wrote:
> > >
> > >  
> > >>Also I have a question regarding domain-0. How will it be represented? Is
> > >>it a VM - the fact that 'guest' is written in the description of the VM
> > >>class makes me think that this might not be the case.
> > >>    
> > >
> > >That's a very good question.  My instinct is to say that dom-0 shouldn't
> > >be part of the list of domains, and that it should be considered part of
> > >the infrastructure.  When we have driver domains, and HVM stub domains,
> > >there will be many of these domains, representing different parts of the
> > >infrastructure, and it seems to me that these are not the same as
> > >"guests" or "VMs".  A VM can be rebooted, migrated (possibly), each time
> > >keeping the same VM, but ending up with a different domain.  A VM is
> > >ultimately the reason that users are running Xen, and the thing that
> > >makes it useful.  For this reason, I don't think that domain 0 is a VM.
> > >
> > >On the other hand, these things are still useful entities -- you might
> > >want to monitor the CPU cost due to each of them, tweak their scheduling
> > >parameters, and so on.  So perhaps they are close enough to being a VM
> > >that we should put them in there, and cope with the slightly special
> > >nature of them as best we can.
> > >
> > >What do people think?
> > >  
> >
> > Even though dom0 is part of the infrastructure (or as Gareth pointed out
> > akin to a HMC), it still needs to be managed and many of the management
> > functions are no different from 'normal' guests.  VCPUs can be
> > hot-plugged and pinned to PCPUs, memory can be added / removed, etc.  
> > From the perspective of adding / removing resources, dom0 is no
> > different than any other VM.
>
> I agree - having Dom0 represented in exactly same way as any other guest
> makes writing management apps very easy because we don't have to special
> case code. Sure there some operations you can't apply to Dom0 (such as
> suspend, migrate, etc), but equally there are some operations you can't
> apply to HVM guests (eg memory ballooning, suspend, migrate). There is
> plenty in common between Dom0 and other guests - which Jim lists here -
> which makes it a net win IMHO to treat Dom0 just like any other DomU.
>
> Regards,
> Dan.
> --
> |=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
> |=-           Perl modules: http://search.cpan.org/~danberr/              -=|
> |=-               Projects: http://freshmeat.net/~danielpb/               -=|
> |=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
> [image removed] _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api