Re: [gentoo-user] xen on new install reboots by itself

["J. Roeleveld" <joost@antarean.org>]

On Friday, April 24, 2015 10:24:06 PM lee wrote:
> "J. Roeleveld" <joost@antarean.org> writes:
> > On Thursday, April 23, 2015 11:02:24 PM lee wrote:
> >> hydra <hydrapolic@gmail.com> writes:
> >> >  You mean the documentation at Gentoo about Xen sucks or the upstream
> >> > 
> >> > documentation? What information are you missing from there? Maybe we
> >> > can
> >> > add  the missing pieces for Xen being more accessible and easier to
> >> > use,
> >> > what do you think? :)
> >> 
> >> I mean the documentation they have on their wiki.  It's a confusing mess
> >> referring to various version with which things are being done
> >> differently.
> > 
> > The problem here is the different "implementations" that exist:
> > - Xen (install and configure yourself, toolset: 'xl' , 'xm' is deprecated)
> > - Citrix and XCP (pre-configured, install on dedicated server, toolset:
> > 'xcp') - OVM (Oracle's implementation, not sure which toolset they use)
> 
> Maybe, maybe not; the documentation is so confusing that I can't really
> tell what it is talking about.

Where did you look?

> >> Could you add missing pieces about why power management --- as in
> >> frequency scaling --- doesn't work
> > 
> > What doesn't work with this?
> > The following seems quite detailed:
> > http://wiki.xen.org/wiki/Xen_power_management
> 
> There was some command to query what frequencies the CPUs are running
> on, and it didn't give any output.  Documentation seems to claim that
> xen can do power management automagically, yet there was no way to
> verify what it actually does.

It works here:
# xenpm get-cpufreq-para all
cpu id               : 0
affected_cpus        : 0
cpuinfo frequency    : max [3101000] min [1600000] cur [1600000]
scaling_driver       : acpi-cpufreq
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 3101000 3100000 2900000 2700000 2500000 2300000 2100000 
1900000 1700000 *1600000
scaling frequency    : max [3101000] min [1600000] cur [1600000]
turbo mode           : enabled

<snipped identical results for other CPU-cores>

Looks like it's actually working and I never configured this.

> > And the commands listed there (for the hypervisor based option) work on my
> > server.
> > 
> >> and what to do about keeping the time
> >> in sync between all VMs when you find out that this doesn't work as the
> >> documentation would have you think it does?
> > 
> > In what way doesn't it work?
> > The clocks are all synchronized and I don't need to use anything like
> > 'ntpd'
> The clocks were off by quite a bit after a while, and I had to use ntp
> to get them in sync.  Some documentation claims you don't need ntp or
> anything; some other documentation apparently tries to explain that
> keeping the clocks in sync cannot work unless the CPU(s) have some
> features having to do with clock consistency while they are in sleep
> states, and yet other documentation seems to say that using ntp cannot
> work because xen screws it off.  In the end, it was recommended to me to
> use ntp, which I found to work.  There was no way to figure out what xen
> was actually doing or not doing towards this, and nobody seemed to know
> how to keep the clocks in sync, other than using ntp, which appears to
> be deprecated.

Which version did you try?
I remember having had clock-issues requiring ntp when I first started using Xen 
over 10 years ago.

--
Joost