The --halt/-H option for the shutdown command is now pointless,
since linux in a guest treats "halt" and "poweroff" identically.
The option is not implemented in xl / libxl and if supplied causes the command
to fail , so remove it from the init and sysconfig scripts.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Options for the shutdown command that are supplied behind the domain id are
ignored. In case of the default xendomains init script this means that it will
not wait for the domains to be actually shutdown.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
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>
These are provided using the "script=" syntax described in
docs/misc/xl-disk-configuration.txt.
The existing hotplug scripts currently conflate two different
concepts, namely that of making a datapath available in the backend
domain (logging into iSCSI LUNs and the like) and that of actually
connecting that datapath to a Xen backend path (e.g. writing
"physical-device" node in xenstore to bring up blkback).
For this reason the script support implemented here is only supported
in conjunction with backendtype=phy.
Eventually we hope to rework the hotplug scripts to separate the to
concepts, but that is not 4.2 material.
In addition there are some other subtleties:
- Previously in the blktap case we would add "script = .../blktap" to
the backend flex array, but then jumped to the PHY case which added
"script = .../block" too. The block one takes precendence since it
comes second.
This was, accidentally, correct. The blktap script is for blktap1
devices and not blktap2 devices. libxl completely manages the
blktap2 side of things without resorting to hotplug scripts and
creates a blkback device directly. Therefore the "block" script is
always the correct one to call. Custom script are not supported in
this context.
- libxl should not write the "physical-device" node. This is the
responsibility of the block script. Writing the "physical-device"
node in libxl basically completely short-cuts the standard block
hotplug script which uses "physical-device" to know if it has run
already or not.
In the case of more complex scripts libxl cannot know the right
value to write here anyway, in particular the device may not exist
until after the script is called.
This change has the side effect of re-enabling the checks for
device sharing aspect of the default block script, which I have tested
and which now cause libxl to properly abort now that libxl properly
checks for hotplug script errors.
There is no sharing check for blktap2 since even if you reuse the
same vhd the resulting tap device is different. I would have preferred
to simply write the "physical-device" node for the blktap2 case but
the hotplug script infrastructure is not currently setup to handle
LIBXL__DEVICE_KIND_VBD
devices without a hotplug script (backendtype phy and tap both end
up as KIND_VBD). Changing this was more surgery than I was happy doing
for 4.2 and therefore I have simply hardcoded to the block script for
the LIBXL_DISK_BACKEND_TAP case.
- libxl__device_disk_set_backend running against a phy device with a
script cannot stat the device to check its properties since it may
not exist until the script is run. Therefore I have special cased
this in disk_try_backend to simply assume that backend == phy is
always ok if a script was
configured. Similarly the other backend types are always rejected
if a script was configured.
Note that the reason for implementing the default script behaviour
in device_disk_add instead of libxl__device_disk_setdefault is
because we need to be able to tell when the script was
user-supplied rather than defaulted by libxl in order to correctly
implement the above. The setdefault function must be idempotent so
we cannot simply update disk->script.
I suspect that for 4.3 a script member should be added to
libxl__device, this would also help in the case above of handling
devices with no script in a consistent manner. This is not 4.2
material.
- When the block script falls through and shells out to a block-$type
script it used to pass "$node" however the only place this was
assigned was in the remove+phy case (in which case it contains the
file:// derived /dev/loopN device), and in that case the script
exits without falling through to the block-$type case.
Since libxl never creates a type other than phy this never happens
in practice anyway and we now call the correct block-$type script
directly. But fix it up anyway since it is confusing.
- The block-nbd and block-enbd scripts which we supply appear to be
broken WRT the hotplug calling convention, in that they seem to
expect a command line parameter (perhaps the $node described above)
rather than reading the appropriate node from xenstore.
I rather suspect this was broken by 7774:e2e7f47e6f79 in November
2005. I think it is safe to say no one is using these scripts! I
haven't fixed this here. It would be good to track down some working
scripts and either incorproate them or defer to them in their existing
home (e.g. if they live somewhere useful like the nbd tools
package).
- Added a few block script related entries to check-xl-disk-parse
from http://backdrift.org/xen-block-iscsi-script-with-multipath-support
and http://lists.linbit.com/pipermail/drbd-user/2008-September/010221.html /
http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html (and
snuck in another interesting empty CDROM case)
This highlighted two bugs in the libxlu disk parser handling of the
deprecated "<script>:" prefix:
- It was failing to prefix with "block-" to construct the actual
script name
- The regex for matching iscsi or drdb or e?nbd was incorrect
- Use libxl__abs_path for the nic script too. Just because the
existing code nearly tricked me into repeating the mistake
I have tested with a custom block script which uses "lvchange -a" to
dynamically add remove the referenced device (simulates iSCSI
login/logout without requiring me to faff around setting up an iSCSI
target). I also tested on a blktap2 system.
I haven't directly tested anything more complex like iscsi: or nbd:
other than what check-xl-disk-parse exercises.
[ Recommit of correct version of 25727:a8d708fcb347, which was mangled
during commit. Sorry. -iwj ]
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>
These are provided using the "script=" syntax described in
docs/misc/xl-disk-configuration.txt.
The existing hotplug scripts currently conflate two different
concepts, namely that of making a datapath available in the backend
domain (logging into iSCSI LUNs and the like) and that of actually
connecting that datapath to a Xen backend path (e.g. writing
"physical-device" node in xenstore to bring up blkback).
For this reason the script support implemented here is only supported
in conjunction with backendtype=phy.
Eventually we hope to rework the hotplug scripts to separate the to
concepts, but that is not 4.2 material.
In addition there are some other subtleties:
- Previously in the blktap case we would add "script = .../blktap" to
the backend flex array, but then jumped to the PHY case which added
"script = .../block" too. The block one takes precendence since it
comes second.
This was, accidentally, correct. The blktap script is for blktap1
devices and not blktap2 devices. libxl completely manages the
blktap2 side of things without resorting to hotplug scripts and
creates a blkback device directly. Therefore the "block" script is
always the correct one to call. Custom script are not supported in
this context.
- libxl should not write the "physical-device" node. This is the
responsibility of the block script. Writing the "physical-device"
node in libxl basically completely short-cuts the standard block
hotplug script which uses "physical-device" to know if it has run
already or not.
In the case of more complex scripts libxl cannot know the right
value to write here anyway, in particular the device may not exist
until after the script is called.
This change has the side effect of re-enabling the checks for
device sharing aspect of the default block script, which I have tested
and which now cause libxl to properly abort now that libxl properly
checks for hotplug script errors.
There is no sharing check for blktap2 since even if you reuse the
same vhd the resulting tap device is different. I would have preferred
to simply write the "physical-device" node for the blktap2 case but
the hotplug script infrastructure is not currently setup to handle
LIBXL__DEVICE_KIND_VBD
devices without a hotplug script (backendtype phy and tap both end
up as KIND_VBD). Changing this was more surgery than I was happy doing
for 4.2 and therefore I have simply hardcoded to the block script for
the LIBXL_DISK_BACKEND_TAP case.
- libxl__device_disk_set_backend running against a phy device with a
script cannot stat the device to check its properties since it may
not exist until the script is run. Therefore I have special cased
this in disk_try_backend to simply assume that backend == phy is
always ok if a script was
configured. Similarly the other backend types are always rejected
if a script was configured.
Note that the reason for implementing the default script behaviour
in device_disk_add instead of libxl__device_disk_setdefault is
because we need to be able to tell when the script was
user-supplied rather than defaulted by libxl in order to correctly
implement the above. The setdefault function must be idempotent so
we cannot simply update disk->script.
I suspect that for 4.3 a script member should be added to
libxl__device, this would also help in the case above of handling
devices with no script in a consistent manner. This is not 4.2
material.
- When the block script falls through and shells out to a block-$type
script it used to pass "$node" however the only place this was
assigned was in the remove+phy case (in which case it contains the
file:// derived /dev/loopN device), and in that case the script
exits without falling through to the block-$type case.
Since libxl never creates a type other than phy this never happens
in practice anyway and we now call the correct block-$type script
directly. But fix it up anyway since it is confusing.
- The block-nbd and block-enbd scripts which we supply appear to be
broken WRT the hotplug calling convention, in that they seem to
expect a command line parameter (perhaps the $node described above)
rather than reading the appropriate node from xenstore.
I rather suspect this was broken by 7774:e2e7f47e6f79 in November
2005. I think it is safe to say no one is using these scripts! I
haven't fixed this here. It would be good to track down some working
scripts and either incorproate them or defer to them in their existing
home (e.g. if they live somewhere useful like the nbd tools
package).
- Added a few block script related entries to check-xl-disk-parse
from http://backdrift.org/xen-block-iscsi-script-with-multipath-support
and http://lists.linbit.com/pipermail/drbd-user/2008-September/010221.html /
http://www.drbd.org/users-guide-emb/s-xen-configure-domu.html (and
snuck in another interesting empty CDROM case)
This highlighted two bugs in the libxlu disk parser handling of the
deprecated "<script>:" prefix:
- It was failing to prefix with "block-" to construct the actual
script name
- The regex for matching iscsi or drdb or e?nbd was incorrect
- Use libxl__abs_path for the nic script too. Just because the
existing code nearly tricked me into repeating the mistake
I have tested with a custom block script which uses "lvchange -a" to
dynamically add remove the referenced device (simulates iSCSI
login/logout without requiring me to faff around setting up an iSCSI
target). I also tested on a blktap2 system.
I haven't directly tested anything more complex like iscsi: or nbd:
other than what check-xl-disk-parse exercises.
[ reran flex/bison -iwj ]
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Since most of the needed work is already done in previous patches,
this patch only contains the necessary code to call hotplug scripts
for nic devices, that should be called when the device is added or
removed from a guest.
Added another parameter to libxl__get_hotplug_script_info, that is
used to know the number of times hotplug scripts have been called for
that device. This is currently used by IOEMU nics on Linux.
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>
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>
Sander Eikelenboom