Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for disk devices, that should be called when the device is added or
removed from a guest.
We will chain the launch of the disk hotplug scripts after the
device_backend_callback callback, or directly from
libxl__initiate_device_{add,remove} if the device is already in the
desired state.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This is from an old Debian bug at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437127
I'm slightly inferring what the configuration which trigger this issue is, the
bug report says:
This code however fails if no slash is present in the address, which is the
case in my configuration:
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:16:17:90:b4:35 brd ff:ff:ff:ff:ff:ff
inet 88.198.12.XXX peer 88.198.12.XXX/32 brd 88.255.255.255 scope global eth0
I hope either Marc or Stefan can correct me if I have surmised wrongly what
this configuration represents.
This function is used in the vif-route configuration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This is based on a patch from Hans van Kranenburg in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658305. Quoting that bug
report:
When configurating a duplicate custom vifname for interfaces in the Xen
dom0 that are added to a bridge (which is obviously a configuration error),
the hotplug scripts fail silently to rename the new vifX.0 to
the custom vifname, if it's already existing.
The result of this, is that the domU will start normally, but no network
traffic between domU and the dom0 bridge is possible, because the vifX.0
never gets added to the bridge.
Worse... when doing xm shutdown on the newly created domU, while
investigating the issue, the interface of another running domU gets shut
down, and remains hanging around in a DOWN state, because it cannot be
removed (the other unrelated domU is still running, but succesfully made
unavailable on the network!).
When starting the new domU again, the interface of the other domU will
be added to the bridge again, and while looking at the output of brctl
show, tcpdump and ping, which make no sense, because everything will
seem to be right, nagios will notify you of another host being down. :|
Note that libxl doesn't actually check the hotplug status yet, this changes
with Rogers hotplug script changes. xend correctly picks the failure up.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
25590:bb250383a4f5 introduced a new locking scheme. Unfortunately it
leaves behind files in /var/run/xen-hotplug. These are spotted as
regressions by the autotester.
Fix this. This involves changing the locking protocol to allow
lockfiles to be deleted (as removing lockfiles is unsafe with a naive
flock-based algorithm).
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In the normal case of a single domain booting with one disk, the disk hotplug
script will fire once. In this case taking out the lock will never cause a
sleep because there's no other concurrent invocations. If a domain has 4 disks
configured, then the hotplug script will fire 4 times, all 4 invocations at
pretty much the same time. If there is even a little load on the system, the
locking function in the shell script will sleep for a few seconds - as many as
5 seconds, or potentially even time out & fail completely.
If say 4 or even more domains each with 4 disks start up at once, that's 16
invocations of the hotplug script running at once. There will be a lot of
sleep's done & because of the very coarse 1 second granularity the delay can
add up significantly.
The change to using flock() removes the arbitrary 1 second sleep, so the very
instant once hotplug script finishes, another can start & there is no repeated
attempts & failures to lock which would add more delay.
In addition the current locking implementation would allow two processes get
the lock simultaneously if one decided the other had timed out.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@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>
This prevents the udev scripts from operating on other tap devices (e.g.
openvpn etc)
Correct the documentation for the "vifname" option which suggested it applied
to HVM tap devices only, which is not the case.
Reported by Michael Young.
Also fix the use of vifname with emulated devices. This is slightly complex.
The current hotplug scripts rely on being able to parse the "tapX.Y" (now
"vifX.Y-emu") name in order to locate the xenstore backend dir relating to the
corresponding vif. This is because we cannot inject our own environment vars
into the tap hotplug events. However this means that if the tap is initially
named with a user specified name (which will not match the expected scheme) we
fail to do anything useful with the device. So now we create the initial tap
device with the standard "vifX.Y-emu" name and the hotplug script will handle
the rename to the desired name. This is also how PV vif devices work -- they
are always created by netback with the name vifX.Y and renamed in the script.
Lastly also move libxl__device_* to a better place in the header, otherwise the
comment about evgen stuff isn't next to the associated functions (noticed jsut
because I was going to add nic_devname near to the setdefault functions)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Remove 4 from default runlevel in xen-watchdog, xend and xendomains.
Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
reserved for local use, the local sysadmin is responsible for symlink
creation in rc4.d.
Runlevel 4 was specified in Default-Start since a very long time. Then
it was copied also to the new xen-watchdog in 21861:fb3649141e19. Until
now this was not an issue since only xencommons is automatically enabled
during package install, and a custom xend and xendomains script is
included in the SuSE packages. Since some time a rpmlint check complains
about the wrong Default-Start entry in xen-watchdog.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson.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>
Move the sxp producing code off into a separate file. It is supported
for legacy reasons and needn't be updated other than the improve
compatibility with xm.
libxl_domain_config is not currently generated by the IDL (adding the
necessary support for Array types is on my to do list) so hand code
the json generation function for now.
Since this rather directly exposes a libxl data structure it's not
clear what sort of forward compatibility guarantees we can
make. However it seems like it should be as stable as libxl's own API
(which we are looking to stabilise)
(Gratuitous string.h include needed for memset in libxl_util.h)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
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>
We need to cope with 0 or more '0' prefixed to '$dev':
# stat -c '%D' "/system.img"
13
# losetup -a
/dev/loop0: [0013]:12062248 (/system.img)
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently, xendomains service will save or migrate all the running domains in
the host on stop.
Change XENDOMAINS_AUTO_ONLY=true. Then on service stop, it will only
save or migrate all VMs under XENDOMAINS_AUTO (/etc/xen/auto), but always
shutdown all the running VMs.
It's a way to cleanly shutdown all the running VMs on system reboot. If you
want to save/migrate a VM, create a link to /etc/xen/auto.
Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The new feature introduced in 23401:a44b12ee2fd3 was broken; it in
general always fails, at least if there are no hotplug scripts.
If there are no hooks, call_hooks ends up running this:
[ -x ".....*.hook" ] && . "..... *.hook"
This does not directly trigger set -e and sigerr. However, it is the
last command exected in call_hooks. So the return status of
call_hooks is an error, and thus a sigerr happens when call_hooks
returns.
The bug affects xl and xm. However xl does not detect failure of the
hotplug script.
Change the script to use if...then rather than &&, as the latter has
very confusing and undesirable semantics.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Improve busy loop device detection after changeset 22773:02c0af2bf280
The intention is not to find the file to be mounted in the losetup -a
output. What matters are existing mounted files with the same dev:inode
as the new file. So the fix is to apply variable expansion which
happens only without double quotes. Otherwise $dev will contain
newlines for hardlinked files, as mentioned in the commit message from
the changeset above.
losetup -a does also truncate long filenames to 62 chars due to ioctl
limitations. This part is fixed with 2.6.37 where the filename can be
obtained from sysfs. As a result very long filenames will be missed.
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>
Otherwise make can search the path relative to certain standard paths
such as /usr/include (e.g., the line '-include $(XEN_ROOT)/.config' in
Config.mk suffers from this).
Signed-off-by: Keir Fraser <keir@xen.org>
In vif-common.sh, set the shell variable "dev" to the new interface
name when interfaces are renamed, and consistently use this variable
in all the vif scripts.
This fixes hotplug of renamed interfaces.
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
From: Patrick Scharrenberg <pittipatti@web.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Patrick Scharrenberg <pittipatti@web.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Apply mtu size from bridge interface also in vif interface.
This depends on a kernel change which allows arbitrary mtu sizes until
the frontend driver has connected to the backend driver. Without this
kernel change, the vif mtu size will be limited to 1500 even with this
change to the vif-bridge script.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix an anomaly in /etc/xen/scripts/network-route.
Currently this script contains
netdev=${netdev:-eth${vifnum}}
ie. netdev is set to eth${vifnum} by default. Unfortunately vifnum
is not set anywhere in the xen code so the default is actually the
broken "eth". And anyway the vif number (which is what vifnum ought
to be) is not relevant.
The patch changes the default to eth0 (which is what the comment at
the top of the file says it should be).
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
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>
"xen-watchdog stop" attempts to kill non existing "watchdogd" but
misses the running "xenwatchdogd". This also provokes errors during
install and Debian package management.
Signed-off-by: user virtual <virtualusr@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
tools/hotplug/Linux/block change for this losetup -a output:
(inode 12 is listed twice due to hardlinks)
/dev/loop0: [0809]:139267 (/abuild/vdisk-sles11_2-disk0)
/dev/loop1: [0809]:139266 (/abuild/vdisk-sles11_1-disk1)
/dev/loop3: [0809]:139267 (/abuild/vdisk-sles11_2-disk0)
/dev/loop5: [0809]:139273 (/abuild/vdisk-sles11_5-disk1)
/dev/loop8: [0809]:12 (/abuild/bootiso-xenpaging-sles11_5.iso)
/dev/loop10: [0809]:12 (/abuild/bootiso-xenpaging-sles11_4.iso)
/dev/loop11: [0809]:139271 (/abuild/vdisk-sles11_4-disk0)
Without this change, $dev would contain /dev/loop8\n/dev/loop10
Applies to 4.0 and 4.1
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Stefano Stabellini <stefano.stabellini@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>
Avoid applying to the bridge and physical network device.
This should un-break dom0 networking in the old xend-creates-bridge
setup (problem introduced in 22493:937488219719).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.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>
Checking for RELATED,ESTABLISHED traffic being sent to a domU requires
connection tracking, which adds unexpected (to most users) load to
dom0. Heavily loaded systems can fill the conntrack tables.
So avoid this, be more liberal in what we accept, and leave it to domU
to police its own input.
Signed-off-by: Keir Fraser <keir@xen.org>
22508:57907b28e51a was unsafe for mutual exclusion. There is a case
that the owner file doesn't exist yet when an atomic mkdir operation
fails.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Most versions of netback do not support setting the MAC address. This
means that c/s 937488219719 causes the hotplug script to break for
vifs, even as it fixes the bridge-wrong-MAC-address problem for tap
devices (used for emulated nics).
The mac-setting operation is not necessary for vifs since they are
hardcoded to fe:ff* anyway.
As a band-aid, add "|| true" to the call to ip link, so that this
error does not cause the hotplug operation to fail. There will still
be an error message printed until we can fix this better.
Suggested-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
When a script using locking.sh is stopped by ctrl-C, the lock file remains.
We have to wait 100 seconds for releasing the lock at the next time.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
While doing block-detach blktap2 disk, tap2 device info is not cleared from
xenstore /vm/uuid/xxx. The reason is in xen-hotplug-cleanup script: when $vm_dev
does not exist, $(xenstore-read "$vm_dev" 2>/dev/null) is also "", won't enter
the block. So, change to use cmd return value to check existence.
Signed-off-by Chunyan Liu <cyliu@novell.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
If a tap device is not given an explicit MAC address it will generate
one randomly.
The behaviour of the Linux bridge is to pickup the lowest MAC address
of any port for use in for ARP, STP etc. If the tap device's randomly
generated MAC address happens to be the lowest then this can cause all
manner of strange networking glitches in both domain 0 and guests when
the bridge suddenly takes over from the previously used MAC address.
We choose FE:FF:FF:FF:FF:FF as it the numerically largest
non-broadcast address. This ensures that the physical NIC device's
port will have the lowest MAC address and therefore be the one picked
up by the bridge.
vif devices already have a MAC address of FE:FF:FF:FF:FF:FF set by
netback already but there is no harm in forcing it a second time in
the hotplug script.
tap devices are added by the "add" event and therefore we should call
setup_bridge_port then as well as for "online" which is caused by vif
devices.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
With newer (pvops) kernels logs get flooded with this iptables
warning: physdev match: using --physdev-out in the OUTPUT, FORWARD and
POSTROUTING chains for non-bridged traffic is not supported anymore
Using the --physdev-is-bridged option prevents this.
See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571634#10
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
While earlier this year some work was done to eliminate libxc's
creation of nodes under /dev (as in some cases it actually got
things wrong), I just found that tapdisk2 does exactly the same.
While I'm not currently aiming at removing this code, I want to
at least suggest some adjustments to the provided rules file.
First of all, the present rule
KERNEL=="blktap[0-9]*", NAME="xen/%k"
matches both blktap1's devices and blktap2's ring devices,
resulting in whoever comes last replacing what was there
before (e.g. a tap2:aio: attach will replace bltap1's
/dev/blktap0 [i.e. the main control device] with the ring device
of the new virtual disk). Therefore we should add a subsystem
qualifier there.
Second, at some udev versions default to using 0660 as the
permissions on nodes it creates. The kernel (with devtmpfs)
defaults to 0600, and hence I'd suggest to also make this
explicit in the rules.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Boris Derzhavets <bderzhavets@yahoo.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Introduce CONFIG_LEAF_DIR, SUBSYS_DIR, INITD_DIR variables to cope
better with variation between distributions.
See docs/misc/distro_mapping.txt for details.
Signed-off-by: Bruce Edge <bruce.edge@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
For example, (vif-script 'vif-bridge bridge=eth1') in xend-config.sxp will
cause vif-setup to attempt to execute 'vif-bridge bridge=eth1' due to a
quoting mismatch. The fix appears to be to remove the extra quotes around
"$script" in vif-setup.
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
From: Anthony PERARD <anthony.perard@citrix.com>
This patch adds a second argument to vif-bridge script. It can be "vif"
or "tap". "vif" give the default behavior and "tap" just add the
interface to the found bridge when the action is "add".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
tools/hotplug/Linux/vif-bridge | 20 ++++++---
tools/hotplug/Linux/vif-common.sh | 70 ++++++++++++++++++++++++---------
tools/hotplug/Linux/xen-backend.rules | 5 +-
tools/libxl/libxl.c | 6 +-
4 files changed, 70 insertions(+), 31 deletions(-)
# 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>