"J. Roeleveld" <jo...@antarean.org> writes: > On Friday, April 24, 2015 10:24:06 PM lee wrote: >> "J. Roeleveld" <jo...@antarean.org> writes: >> > On Thursday, April 23, 2015 11:02:24 PM lee wrote: >> >> hydra <hydrapo...@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?
Everywhere I could find. The xen wiki is particularly messy. >> >> 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. It didn't work for me. >> > 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. The version in Debian --- I don't remember which one it was. Debian was the only distribution I could get it to work with at all, and the VMs also were Debian because there isn't a good way to install an operating system in a VM. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
