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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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