On SuSE the configuration files in /etc/sysconfig/ will be updated in
a smart way from templates found in /var/adm/fillup-templates/
Introduce new variable SYSCONFIG_DIR for Linux installations. Now
only one place needs patching, or it can be specified as option to
make(1).
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>
_release_lock should be used instead of release_lock.
sigerr is introduced so that it can be redefined by
xen-hotplug-common.sh to a version which writes error status to xenstore.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.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>
Previously, the default "network-script",
/etc/xen/scripts/network-bridge, would attempt to do its horrid work
even if you had already set everything up in /etc/network/interfaces.
Setting up your bridge in /etc/network/interfaces is:
* easy
* required for libxl since libxl never does it for you
* not a fragile piece of lunacy
* properly documented
* the way everyone would expect it to work
In this small patch we make it so that the default config for xend
doesn't mess about on startup if you already have a bridge, and
doesn't mess about on shutdown unless your first-named bridge (eth0 or
xenbr0, normally) doesn't also have a physical interface named
p<whatever> (peth0 or pxenbr0) enslaved to it. The latter test is not
ideal but will hopefully do from now until the time xend finally dies.
We also fix the "documentation" - ie, the comments in the default
xend-config.sxp - to correspond to reality.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Now the init script is called xencommons and, as the name suggests, it
is a common script between xl and xend because it is used to start
xenconsoled, xenstored and xenbackendd and the initialization of these
three daemons has been removed from xend. The global
xen_toolstack=xl/xend variable has been removed. Regarding the
network setup, I made the vif scripts follow the same pattern as the
other scripts in xen-backend: a new script called vif-setup is
executed unconditionally. vif-setup is going to do the right thing
depending on the value of the environmental variable "script" (same
technique used before), defaulting to vif-bridge. In the common
scenario the toolstack doesn't need to set the variable "script"
because vif-bridge is going to be called anyway. There is no global
network script to setup the network bridges with xl, so if you are
using xl without xend, you need to manually configure the bridges
using your distro network setup, or, if you are lazy, you can just add
something like:
/etc/xen/scripts/network-bridge start
to your rc.local.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
this patch adds an init script for xl, so that it can be used without
xend installed on the system. In cases in which both toolstacks are
present, only one init script will be run, dependening on the value of
xen_toolstack in /etc/sysconfig/xen_toolstack. Please note that a
correct value of xen_toolstack (either xl or xend), is required now.
The network script and the vif script to be used with xl can be
specified in /etc/sysconfig/xenlightdaemons. Xl sets the vif script
to xl-vif-script by default, that reads /etc/sysconfig/xenlightdaemons
and calls the vif script set there. A port to a debian system should
be straightforward, just replacing /etc/sysconfig with /etc/default
everywhere.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
c/s 20393 breaks existing domain configuration that contains
spaces in the vbd path name. Fixed by this trivial patch which
provides missing quotes.
Signed-off-by: Jim Fehlig <jfehlig@novell.com>
I noticed that 2 scripts in Xen 4.0.0 are calling "gawk". Normally, in
most distributions, gawk is considered a specific version of awk.
Calling "gawk" and not "awk" generally means that you need
specificities of the "g" version of awk, as opposed to "mawk" which is
another implementation of the same tool.
So, unless I misread the scripts, Xen doesn't need to use gawk but
just any implementation of awk, and the attached patch can safely be
applied.
If I am wrong (which I don't think I am at the first look) and that
there's a reason why gawk is used and not awk, then IMHO, the toplevel
README should mention it in the prerequisites.
From: Thomas Goirand <thomas@goirand.fr>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Perhaps this should even be further generalized (e.g. to remove any
"[!/]*:" pattern prefixes) to be more forward compatible?
Signed-off-by: Jan Beulich <jbeulich@novell.com>
I saw the following message when I created or destroyed two bridges by
using network-bridge script at same time. Of course names of the
bridges are different. But, a temporal name "tmpbridge" is used by
the script to create or destroy the bridges. I think that the message
was shown by "tmpbridge".
SIOCSIFNAME: File exists
This patch avoids race condition when creating or destroying the
bridges.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
The failure to read "backend/tap/<domid>/*" in the xenstore is a usual
case since the domain is gone after xenstore-ls command is executed.
The error should be ignored.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
You can see the following slides to understand the usage.
http://www.xen.org/files/xensummit_intel09/PVUSBStatusUpdate.pdf
Limitations:
"xm usb-hc-create" accepts up to 16 ports, but, current usbfront
can work with up to 15 ports. This may be bug and I'm preparing
to fix it.
This xm/xend support requires linux-2.6.18-xen.hg c/s 939 or above.
I recommend latest tip.
Signed-off-by: Noboru Iwamatsu <n_iwamatsu@jp.fujitsu.com>
- Use the device and inode information provided by losetup to find
if the vbd backing file is in use on another vbd.
- Use losetup to find a free loopback device.
Signed-off-by: Gary Grebus <gary.grebus@oracle.com>
Avoid races between hotplug "add" and "remove" leading to "leaked"
loopback devices.
- Don't setup loopback device if xend is no longer waiting for the
vbd.
- Use the lock file to avoid add/remove races.
Signed-off-by: Gary Grebus <gary.grebus@oracle.com>
pvops dom0 kernels have a separate xenfs which has to be mounted on
/proc/xen. Systems with older configurations don't have xenfs listed
in fstab, and it can sometimes make sense to keep it that way (for
example, if the dom0 wants to boot a native-only kernel too).
The attached patch to the script which ends up in /etc/init.t/xend
mounts /proc/xen if it appears to be necessary.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
The attached patch enables to set the environment variables for xend
in /etc/sysconfig/xend.
There are four variables.
XENCONSOLED_TRACE=3D[none|guest|hv|all]
XENSTORED_ROOTDIR=3D/var/lib/xenstored
XENSTORED_TRACE=3D[yes|on|1]
XENBACKENDD_DEBUG=3D[yes|on|1]
The XENCONSOLED_TRACE and XENSTORED_ROOTDIR take strings for each
command's options. And if thease variables have non-zero strings, then
export them.
If the XENSTORED_TRACE and XENBACKENDD_DEBUG take either "yes", "on"
or "1" then export them.
From: Kazuhiro SUZUKI <kaz@jp.fujitsu.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
currently the function same_vm in block-common.sh is the one
responsible for detecting if two block devices can be used at the same
time by two VMs. This can be allowed in few specific cases: when the
two VMs are actually the same VM and when the two VMs are the guest
and its stubdomain. We need to expand these exceptions to handle
properly save restore issues: this patch adds to the exceptions the
case when two VMs are the same VM because of save\restore races, and
when two VMs are the guest and the stubdomain of the previous guest,
again during save\restore.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In changset 19540 a bug was introduced in the fib_iptable function in
vif-common.sh that incorrectly checks the exit status of iptables --
it always believes iptables has failed even when it hasn't.
The attached patch fixes that. It's also bug 1490.
Signed-off-by: John Haxby <john.haxby@oracle.com>
blktap2 devices must be handled differently than blktap2
devices. blktap2 devices require a sysfs write to close the underlying
device, as well as extra sysfs writes when the domU is
paused/unpaused. The differences between blktap1 and blktap2 are great
enough to warrant the creation of a new device class, 'tap2', and
device controller for blktap2 devices.
* add a new device controller (Blktap2Controller) and device class
(tap2) for blktap2 devices
* move blktap2 specific code from DevController to Blktap2Controller
* if possible, check xenstore to determine block device class
* use vmpath (/vm/<uuid>/) when releasing devices
* modify linux hotplug cleanup script to handle blktap2 device
removal
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
Ubuntu puts /var/lock on tmpfs, so we should create /var/lock at
startup, rather than at installation time.
Signed-off-by: Jun Koi <junkoi2004@gmail.com>
udev removed the udevinfo symlink from versions higher than 123 and
xen's build-system could not detect if udev is in place and has the
required version.
Signed-off-by: Marc-A. Dahlhaus <mad@wol.de>
- Have the buid system generate a file which exports the install paths
for the hotplug scripts and stubdom / stubdom-dm
- Move file generation code from tools/python/Makefile into a gmake
macro
in Config.mk to avoid maintenance of three duplicates each with its
own
tweaks and bugs
- Export gmake variables into ioemu as shell variables
for upcoming ioemu patches
- Do above as a gmake macro to avoid maintenance of several duplicates
- Adjust hotplug scripts to find the right xen binaries from the
install directory
- Adjust stubdom-dm to use the install directories
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
When we want to setup a bridge without a ip address, function
do_ifup will not activate the bridge.
We should make the bridge active, then vif-bridge can work on the
bridge.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
iptables cannot correctly handle situations when more than one command
is trying to set netfilter rules. In such situations, iptables may fail
with EAGAIN, which results in iptables: Unknown error
18446744073709551615.
Such situation can easily happen when multiple network devices are
configured for a domain as vif hotplug scripts are called in parallel
for all of the network devices.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Allow 'file' based disks, that are blkback based disks, to be shared
between the guest domain and the stubdom. It does so exploiting the
same exception introduced in the previous patch "stubdoms phy disks
sharing". Now we can remove the hack in stubdom-dm that forces "file"
disks to be opened using blktap instead of blkback.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
For now hardcode /etc w/o a prefix as there are hardcoded
config paths in the code which would break otherwise.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
If ${netdev} is bonding, brctl addif ${bridge} ${pdev} fails:
can't add ${pdev} to bridge ${bridge}: Invalid argument
Because ${pdev} has no slaves at this point.=20
# Notice that ifdown ${netdev} clears slaves of ${netdev}.
This patch restores slaves before add_to_bridge2 ${bridge} ${pdev}.
Signed-off-by: KUWAMURA Shin'ya <kuwa@jp.fujitsu.com>
This patch makes two small changes to dom0 iptables rules that permit
(and revoke) domU network access.
First:
Currently, a rule intended to allow domU network access is appended to
the end of the FORWARD chain, where it can be preempted by other =20
rules. This patch causes the rule to be inserted at the top, where
it's more likely to have the intended effect.
Second:
In some cases (e.g. Fedora 9's default iptables configuration), the
first rule alone is insufficient to permit two-way packet flow. This
patch adds a second rule to the FORWARD chain that permits replies to
domU network requests to reach the domU vif.
Signed-off-by: Chris Bookholt <hap10@tycho.ncsc.mil>
Olaf Hering