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

RE: [Xen-users] How to get dom0 configuration when running in domU?


  • To: "Hannes Kuehnemund" <hannes.kuehnemund@xxxxxxx>
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Tue, 22 May 2007 18:59:48 +0200
  • Cc: Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 22 May 2007 09:58:33 -0700
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: Aceci4Tn/UhwVDU4QJ+kKDIwZST8GgABlPmA
  • Thread-topic: [Xen-users] How to get dom0 configuration when running in domU?

 

> -----Original Message-----
> From: Hannes Kuehnemund [mailto:hannes.kuehnemund@xxxxxxx] 
> Sent: 22 May 2007 17:08
> To: Petersson, Mats
> Cc: Xen Users
> Subject: Re: [Xen-users] How to get dom0 configuration when 
> running in domU?
> 
> Petersson, Mats wrote:
> >> -----Original Message-----
> >> Hi,
> >>
> >> is there any chance to get the dom0 configuration information 
> >> (which is 
> >> available in dom0 by 'xm list --long Domain-0' or 'xm 
> vcpu-list' in 
> >> general) being in a domU?
> >>
> >> The background is, only having access to domU I'd like to know the 
> >> mapping of my virtual CPU's. How can I figure out if my 4 
> >> virtual CPU's 
> >> aren't assigned to one single physical CPU. This information 
> >> is needed 
> >> for sizing matters.
> > 
> > This information SHOULDN'T be available to the guest for security
> > reasons - guest shouldn't even be able to tell that it's 
> not a physical
> > machine [although this is probably not to hard to do with 
> "uname -a" or
> > by measuring the timing of certain operations]. I'm not 
> sure if you can
> > trick around and for example read CPUID to find the APICID of the
> > VCPU's, for example [probably not, because that would break SMP in
> > guest, I think]. 
> > 
> > Some possible option(s) for checking this are:
> > 1. use some sort of network protocol to get back to Dom0 
> (or a client
> > supported by Dom0). Most trivial is "ssh <dom0> xm ...".
> > 
> > 2. Try to determine it by running variable loads on the 
> guest - such as
> > run one thread, then two threads, then three, then four 
> (etc).  If you
> > have fewer physical CPU's than VCPU's, then there will be a 
> proportional
> > slow-down per thread when you get above the number of 
> physical CPU's.
> > [That is, of course, if you don't have any other competing 
> tasks on the
> > same physical CPU(s), but then on the other hand, if you have four
> > physical CPU's, but share them with another guest, that 
> would amount to
> > the same thing as not having a "full" set of CPUs in the 
> first place,
> > right?]. 
> 
> Thanks for your comments so far. I agree, that this information 
> shouldn't be available by DEFAULT. But if I want this 
> information, and I 
>   have control over dom0, there must be a way to get it. I 
> agree, that a 
> domU should not get any information if this feature is not enabled in 
> dom0 (which should be the default)!
> 
> Of course one can install some remote management software in 
> every domU 
> which queries a configured dom0, but after a migration this will not 
> work, as the dom0 the domU is running on changed.

Well, if you let Dom0 that owns the DomU update some table (a file or
data-base-table or some such), then you can let DomU ask the server that
owns the table (which doesn't have to be the owning Dom0, of course),
and that could be a single server (with fallback if necessary). As long
as you do this frequently enough it should work (and I guess you need to
"frequently enough" check the CPU sharing situation as well, since it
may well be that it's changes during the lifetime even without
migration). 

Having DomU access the local Dom0 via SSH is of course not even loosely
a "safe" thing to allow. 

> 
> This feature is already available on zOS and VMWare (through 
> the VMWare 
> SDK), thus it should also be available on Xen.

Ok. I wasn't aware of this feature existing in other VMM's (I haven't
done much work on competing products). 
> 
> But taken from your answer, this feature is sadly not yet available. 
> Anyway, does anyone know where to ask for new features of Xen?

The Xen-devel forum, as far as I know there's no "feature request" forum
at the moment. 

--
Mats
> 
> > --
> > Mats
> 
> Thanks,
>    Hannes
> 
> 
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.