Upstream QEMU doesn't support -nographic with -daemonize unless monitor,
serial and parallel outputs are all redirected:
/* According to documentation and historically, -nographic redirects
* serial port, parallel port and monitor to stdio, which does not work
* with -daemonize. We can redirect these to null instead, but since
* -nographic is legacy, let's just error out.
* We disallow -nographic only if all other ports are not redirected
* explicitly, to not break existing legacy setups which uses
* -nographic _and_ redirects all ports explicitly - this is valid
* usage, -nographic is just a no-op in this case.
*/
Considering that we do want to redirect them to /dev/null anyway, do so.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- handled reject vs 26352:9a1610c1e564 "xencommons: Stop QEMU in
do_stop()" and rewrapped the resulting long line ]
Committed-by: Ian Campbell <ian.campbell@citrix.com>
do_stop() is invoked by "restart" action. We can get multiple QEMUs started up
for Dom0 if we don't kill previous ones.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Older kernels, such as those found in Debian Squeeze:
* Have bugs in handling of AIO into foreign pages
* Have blktap modules, which will cause qemu not to use AIO, but
which are not loaded on boot.
Attempt to load blktap in xencommons, to make sure modern qemu's which
use AIO will work properly on those kernels.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Prefer to load blktap2 if it exists. This is the name of the driver in
classic-Xen ports, while in mainline kernels the driver is called just
blktap.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <JBeulich@suse.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Load all known backend drivers fron xenlinux and pvops based dom0
kernels. There is currently no code in xend or libxl to load these
drivers on demand. Currently libxl has also no helpful error message if
a backend driver is missing.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
- Spawn a QEMU instance at boot time to handle disk local attach
requests.
- Implement libxl__device_disk_local_attach for QDISKs in terms of a
regular disk attach with the frontend and backend running in the same
domain.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Upstream the "xen/acpi-processor: C and P-state driver that
uploads said data to hypervisor." takes care of uploading power information
information that normally a cpu frequency scaling driver would using
in the initial domain. We want the hypervisor to take that data and
make good usage of it.
Fortunatly for us we do not have to worry about the native cpu frequency
scaling drivers being loaded first, as the upstream commit:
"xen/cpufreq: Disable the cpu frequency scaling drivers from loading."
takes care of that. Meaning we can load the xen-acpi-processor at any time.
By default that driver is built as a module - and since we are
the only user of it - we should load it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
24905:2b5cf6bde62d accidentally contained a change to
tools/hotplug/Linux/init.d/xencommons. That change is probably OK but
should not be in 24905 so remove it.
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
LSB defines runlevel 4 as "reserved for local use, default is
normal/full multiuser"
The current behaviour of insserv in openSuSE 11.4 and SLES11SP2 is that
xencommons gets a symlink in /etc/init.d/rc4.d/ due to the 4 in the
Default-Start: line. As a result insserv will print a warning:
insserv: warning: current stop runlevel(s) (2 3 5) of script `xencommons' overwrites defaults (2 3 4 5).
Since the local admin is responsible to create all symlinks manually in
/etc/init.d/rc4.d/ the xencommons script should not automatically enable
itself in runlevel 4.
So, remove the 4 from Default-Start: line.
Note: This change will not automatically remove old/stale xencommon
symlinks in /etc/init.d/rc4.d/ during a package upgrade.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
oxenstored is an ocaml implementation of the xenstore daemon. It is faster,
more scalable and more reliable than the C xenstored.
In particular the transaction model in oxenstored does not involve taking a
complete copy of the database and aborting on any (even non-conflicting) other
change.
There is a paper on the design and implementation of oxenstored at
http://gazagnaire.org/pub/GH09.pdf which includes a performance evaluation and
comparison with the C daemon etc.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
There is currently no code in the kernel to trigger autoload of the
evtchn or gntdev drivers. Load them manually during xencommons start.
Handle both pvops and xenlinux module names.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently xencommons prints an error that /proc/xen/capabilities does
not exist when started on a non-xen kernel.
Update the xencommons script to run only when needed:
- do not run if /proc/xen does not exist
- check if /proc/xen/capabilities exists before doing the grep for dom0
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Changset 22806:eefb8e971be5 broke 'xl'.
After starting the xenstored, xenconsoled, xenbackendd and running xl
create I get this:
libxl: error: libxl.c:53:libxl_ctx_init Is xenstore daemon running?
failed to stat /var/run/xenstore.pid: No such file or directory
cannot init xl context
The reason for the failure is that the NetBSD startup script
creates the file
/var/run/xenstored.pid
but libxl checks for
/var/run/xenstore.pid
Attached patch makes this consistent across Linux and NetBSD by
changing the Linux name (to the more-conventional food.pid form).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This is the default runlevel on a Debian system.
In addition update-rc.d complains:
update-rc.d: warning: xencommons stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (1)
and it seems reasonable to stop the daemons during shutdown or reboot
so make that change as well.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Since 22187:c41252a55a0a we have been installing our example
xencommons settings file in either /etc/sysconfig or /etc/default,
depending on whether /etc/sysconfig exists.
However I omitted to add the code to /etc/init.d/xencommons to
actually read either version of the file, although every other init
script seems to have it.
An effect of this misplaced/unread file is that the automatic tests
don't cause xenconsoled to collect serial logs, because the tester
edits whichever file actually exists.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
# User Olaf Hering <olaf@aepfle.de>
# Date 1280140115 -3600
# Node ID 8c3e1e8ddd599371d882b17996be88b545119ccb
# Parent 2092c06f9467747da608c448ddd01e2f1f82290a
tools/hotplug: init.d should test for /proc/xen/capabilities being a file
Correct test for /proc/xen/capabilities
It is a file, not a directory.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
"Default-Enabled:" is not a LSB keyword.
Remove it from the LSB section.
This avoids an openSuSE buildcheck warning and we are not aware of any
reason why it should be kept.
From: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Modified-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
On one of my boxes, the xenstore-write setting dom0's name starts
before xenstored is actually ready to handle the connection properly,
resulting in the name set failing. Wait for xenstored to be up and
responding to reads before continuing, timing out after 30 seconds.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Fix the xencommons init script chkconfig configuration since the
priority was missing here and chkconfig was complaining about invalid
chkconfig script so I added both start and stop priorities to the
chkconfig line and it was working fine, the script was successfully
added to chkconfig when using `chkconfig --add xencommons` and
management using the chkconfig utility was now possible.
Tested on RHEL-5 Server with Xen-4.1-unstable installed, running on
PVops kernel 2.6.32.15 and it was working fine.
Signed-off-by: Michal Novotny <minovotn@redhat.com>
If xenfs is compiled as a module, now cannot complete
'service xencommons start', modprobe xenfs can fix it.
Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com>
Stefano Stabellini
Wei Liu
Ian Campbell
Olaf Hering
Fabio Fantoni
Konrad Rzeszutek Wilk
Ian Jackson
Jim Fehlig
Christoph Egger
Keir Fraser