With the current libxl implementation the control domain will remove both
the frontend and the backend xenstore paths of a device that's handled by a
driver domain. This is incorrect, since the driver domain possibly needs to
access the backend path in order to perform the disconnection and cleanup of
the device.
Fix this by making sure the control domain only cleans the frontend path,
leaving the backend path to be cleaned by the driver domain. Note that if
the device is not handled by a driver domain the control domain will perform
the removal of both the frontend and the backend paths.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reported-by: Alex Velazquez <alex.j.velazquez@gmail.com>
Cc: Alex Velazquez <alex.j.velazquez@gmail.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The current flow of the devd helper (in charge of launching hotplug scripts
inside of driver domains) is to wait for the device backend to switch to
state 6 (XenbusStateClosed) and then remove it. This is not correct, since
a domain can reconnect it's PV devices as many times as it wants.
In order to fix this, introduce the following logic: the control domain will
set the "online" backend node to 0 when it wants the driver domain to
disconnect the device, so now the condition applied in devd is that "state"
must be 6 and "online" 0 in order to proceed with the disconnection.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reported-by: Alex Velazquez <alex.j.velazquez@gmail.com>
Cc: Alex Velazquez <alex.j.velazquez@gmail.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The callback functions provided by users must take an rc value. This
rc value can be ERROR_TIMEDOUT or ERROR_ABORTED.
Users of xswait are now expected to deal correctly with
ERROR_ABORTED. If they experience this, it hasn't been logged.
And the caller won't log it either since it's not TIMEDOUT.
Luckily this is correct, so we can just change the doc comment.
Currently nothing generates ERROR_ABORTED; in particular the timeouts
cannot in fact signal abort requests.
There should be no publicly visible change except that some error
returns from libxl will change from ERROR_FAIL to ERROR_TIMEDOUT, and
some changes to debugging messages.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: ABORTED not CANCELLED.
The internal user of libxl__async_exec_start et al now gets an rc as
well as the process's exit status.
For now this is always either 0 or ERROR_FAIL, but with ao
abort requests this will possibly be ABORTED or TIMEDOUT too.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: Improve doc comment as suggested by Ian C.
v2: New patch due to rebause; v1 had changes to device_hotplug_*
scripts instead.
Callback now gets unambiguous information about error situation:
previously, if only thing that went wrong was that child died
badly, rc would be FAILED, which was unambigously; now rc=0.
Add a comment document the meaning of the rc and status parameters
to the callback.
Change the timeout setup functions to take a libxl__ao, not a
libxl__gc. This is going to be needed for ao abort, because timeouts
are going to be a main hook for ao abort requests - so the timeouts
need to be associated with an ao.
This means that timeouts can only occur as part of a long-running
libxl function (but this is of course correct, as libxl shouldn't have
any global timeouts, and indeed all the call sites have an ao).
Also remove the gc parameter from libxl__async_exec_start. It can
just use the gc from the ao supplied in the aes.
All the callers follow the obvious patterns and therefore supply the
ao's gc to libxl__async_exec_start and the timeout setup functions.
There is therefore no functional change in this patch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Yang Hongyang <yanghy@cn.fujitsu.com>
CC: Wen Congyang <wency@cn.fujitsu.com>
CC: Lai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: Wen Congyang <wency@cn.fujitsu.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: This patch split off from "Permit timeouts to signal cancellation".
Rebased; consequently, deal with libxl__async_exec_start.
CC'd authors of the libxl__async_exec_* functions.
Replace the separate timeout and xenstore watch with use of
libxl__xswait*.
Different control flow, but no ultimate functional change apart from
slight changes to the text of error messages.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Convert all plain ints and strings which are used for xenbus "state"
files to xenbus_state. This makes it easier to find code which deals
with backend/frontend state changes.
Convert usage of libxl__sprintf to GCSPRINTF.
No change in behaviour is expected by this change, beside a small
increase of runtime memory usage in places that used a string constant.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Originally both QEMU traditional and QEMU upstream used hardcoded
/local/domain/0 paths. This patch changes the protocol to use
/local/domain/$dm_domid path.
For QEMU traditional and upstream without stubdom, $dm_domid is 0 so
the path is in fact still /local/domain/0.
For QEMU traditional stubdom, this is incompatible protocol change.
However QEMU traditional is shipped with Xen so we are allowed to do
such change. This change requires to corresponding QEMU traditional
changeset.
There is no compatibility issue with QEMU upstream stubdom, because QEMU
upstream stubdom doesn't exist yet.
Watch /local/domain/$dm_domid/device-model/$domid/state, wait until
state turns "running" then unpause guest.
LIBXL_STUBDOM_START_TIMEOUT is the timeout used wait for stubdom to be
ready. My test on a very old machine (Core 2 6400) showed that it might
need more than 20s before the stubdom is ready to serve DomU.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This reverts commit 54c2e621c5 which
should have included a corresponding QEMU_TAG update but did not.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Originally both QEMU traditional and QEMU upstream used hardcoded
/local/domain/0 paths. This patch changes the protocol to use
/local/domain/$dm_domid path.
For QEMU traditional and upstream without stubdom, $dm_domid is 0 so
the path is in fact still /local/domain/0.
For QEMU traditional stubdom, this is incompatible protocol change.
However QEMU traditional is shipped with Xen so we are allowed to do
such change. This change needs to work with corresponding QEMU
traditional changeset.
There is no compatibility issue with QEMU upstream stubdom, because QEMU
upstream stubdom doesn't exist yet.
Watch /local/domain/$dm_domid/device-model/$domid/state, wait until
state turns "running" then unpause guest.
LIBXL_STUBDOM_START_TIMEOUT is the timeout used wait for stubdom to be
ready. My test on a very old machine (Core 2 6400) showed that it might
need more than 20s before the stubdom is ready to serve DomU.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch resurrects 11a63a166. The previous patch had a bug that
wrong "physical-device" was written to xenstore causing block script
execution fail. This patch fixes that problem.
Following configurations have been tested:
1. Raw file and PV
2. Raw file and HVM
3. Block device and PV
4. Block device and HVM
Creation / destruction / local migration all worked.
Original commit message from 11a63a166:
Modify libxl and hotplug script to allow raw format file to use phy
backend.
The block script now tests the path and determine the actual type of
file (block device or regular file) then use the actual type to
determine which branch to run.
With these changes, plus the current ordering of backend preference (phy
> qdisk > tap), we will use phy backend for raw format file by default.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This can be used to fork children to allow the asynchronous execution
of system calls which only come in a synchronous variant. This will
be useful for Remus, in the following patches.
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
libxl__multidev_prepare_with_aodev is similar to libxl__multidev_prepare,
but takes a libxl__ao_device as an extra argument.
libxl__multidev_prepare is now a wrapper around
libxl__multidev_prepare_with_aodev.
This new internal API will be used by the Remus device abstract layer
for handling various Remus devices.
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Now a caller who wants to be able to do other work when the aodev
completes can put their own callback into the aodev, and make the
multidev machinery aware that the particular aodev is complete (from
the point of view that multidev should have) whenever it likes.
No functional change in this patch.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Originally the code allowed users to attach the same device more than
once. It just stupidly overwrites xenstore entries. This is bogus as
frontend will be very confused.
Introduce a helper function to check if the device to be written to
xenstore already exists. A new error code is also introduced.
The check and add are within one xs transaction.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On FreeBSD ZVOLs/disks/partitions are char devices, so libxl must
allow it's usage. This is already taken care in the OS-specific bits
of libxl by libxl__try_phy_backend, so remove the generic gate.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl__initiate_device_remove() had a preexisting error path issue where
libxl_dominfo_dispose() could be called on a libxl_dominfo object before it
had been initialised with libxl_dominfo_init().
This was safe until c/s ab44401 added the pointer ssid_label, which point
libxl_dominfo_dispose() free()s.
Unconditionally initialise info in libxl__initiate_device_remove() before
taking an error path which will free it.
Coverity-ID: 1223212
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
1.introduce asynchronous execution API:
libxl__async_exec_init
libxl__async_exec_start
libxl__async_exec_inuse
2.use the async exec API to execute device hotplug scripts
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Plumb hotplug scripts' stdout to stderr. That way if they print
anything (which really they shouldn't), it won't get mixed up with
the application's stdout. (Eg, perhaps with an xl migration
stream...)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Vasiliy Tolstov <v.tolstov@selfip.ru>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When Qemu is launched from a driver domain to act as a PV disk
backend we can make sure that Qemu is running before detaching
devices, so there's no need for the bodge there.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Synchronize the clean up of the backend from the toolstack domain when
the driver domain has actually finished closing the backend for the
device.
This is accomplished by waiting for the driver domain to remove the
directory containing the backend keys, then the toolstack domain will
finish the cleanup by removing the empty folders on the backend path.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
libxl__wait_for_device_model blocks, with the ctx lock held, waiting
for a response from the device model. If the dm doesn't respond
quickly (for example, because it has crashed), this may block the
whole process. Explain this in a comment, rename the function to
libxl__wait_for_device_model_deprecated, and explain what to use
instead.
libxl__wait_for_offspring is the core implementation for the above.
Its name leads people to think it might be generally useful for
waiting for children, which is far from the case. It only waits for
xenstore. Also it has the problems described above. Explain this,
rename it to libxl__xenstore_child_wait_deprecated, and explain what
to use instead.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Replace libxl__sprintf, LIBXL__LOG and LIBXL__LOG_ERRNO with new
"Convenience macros": GCSPRINTF, LOG, LOGE in tools/libxl/libxl_device.c
Signed-off-by: Alexandra Sava <alexandrasava18@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
libxl currently refuses to execute hotplug scripts if the backend
domid of a device is different than LIBXL_TOOLSTACK_DOMID. This will
prevent libxl from executing hotplug scripts when running on a domain
different than LIBXL_TOOLSTACK_DOMID, we should instead check if
backend_domid is different than current domid.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
There are some disk formats commonly supported by both qdisk and blktap.
As qdisk is better supported and blktap is unmaintained, we choose qdisk
over blktap whenever possible.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Matthew Daley has observed that the PV console protocol places sensitive host
state into a guest writeable xenstore locations, this includes:
- The pty used to communicate between the console backend daemon and its
client, allowing the guest administrator to read and write arbitrary host
files.
- The output file, allowing the guest administrator to write arbitrary host
files or to target arbitrary qemu chardevs which include sockets, udp, ptr,
pipes etc (see -chardev in qemu(1) for a more complete list).
- The maximum buffer size, allowing the guest administrator to consume more
resources than the host administrator has configured.
- The backend to use (qemu vs xenconsoled), potentially allowing the guest
administrator to confuse host software.
So we arrange to make the sensitive keys in the xenstore frontend directory
read only for the guest. This is safe since the xenstore permissions model,
unlike POSIX directory permissions, does not allow the guest to remove and
recreate a node if it has write access to the containing directory.
There are a few associated wrinkles:
- The primary PV console is "special". It's xenstore node is not under the
usual /devices/ subtree and it does not use the customary xenstore state
machine protocol. Unfortunately its directory is used for other things,
including the vnc-port node, which we do not want the guest to be able to
write to. Rather than trying to track down all the possible secondary uses
of this directory just make it r/o to the guest. All newly created
subdirectories inherit these permissions and so are now safe by default.
- The other serial consoles do use the customary xenstore state machine and
therefore need write access to at least the "protocol" and "state" nodes,
however they may also want to use arbitrary "feature-foo" nodes (although
I'm not aware of any) and therefore we cannot simply lock down the entire
frontend directory. Instead we add support to libxl__device_generic_add for
frontend keys which are explicitly read only and use that to lock down the
sensitive keys.
- Minios' console frontend wants to write the "type" node, which it has no
business doing since this is a host/toolstack level decision. This fails
now that the node has become read only to the PV guest. Since the toolstack
already writes this node just remove the attempt to set it.
This is a security issue, XSA-57.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Prevent hotplug script execution from libxl if device is on a
different domain.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Don't try to check physical devices if they belong to a domain
different than the one where the toolstack is running. This prevents
the following error when trying to use storage driver domains:
libxl: debug: libxl_create.c:1246:do_domain_create: ao 0x1819240: create: how=(nil) callback=(nil) poller=0x1818fa0
libxl: debug: libxl_device.c:235:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=phy
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=xvda, backend phy unsuitable as phys path not a block device
libxl: error: libxl_device.c:278:libxl__device_disk_set_backend: no suitable backend for disk xvda
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The commit a8a1f236a2 "libxl: Only call stat() when adding a disk if we
expect a device to exist." changed things to only stat the file when the phy
backend was explicitly requested. This broke the case where we are probing and
would normally be able to decide on the phy option.
Since the intention of that commit was to allow for backends with no explicit
file in dom0 (i.e. network remote backend such as ceph) the lowest impact fix
appears to be to make that explicit. It turns out that tap disk can also
potentially handle such paths.
The only backend which requires a local file/device is PHY but we need to
handle UNKNOWN too in order for subsequent probing to work. Note that it is
not possible to autoprobe the backend if the path is not a local object, so we
don't need to worry about autoprobing ceph etc.
This should probably be revisited to rationalize the probing.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
We consider calling stat() a helpful error check in the following
circumstances only:
1. the disk backend type must be PHYsical
2. the disk backend domain must be the same as the running libxl
code (ie LIBXL_TOOLSTACK_DOMID)
3. there must not be a hotplug script because this would imply that
the device won't be created until after the hotplug script has
run.
With this fix, it is possible to use qemu's built-in block drivers
such as ceph/rbd, with a xl config disk spec like this:
disk=[ 'backendtype=qdisk,format=raw,vdev=hda,access=rw,target=rbd:rbd/ubuntu1204.img' ]
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
This patch adds vtpm support to libxl. It adds vtpm parsing to config
files and 3 new xl commands:
vtpm-attach
vtpm-detach
vtpm-list
Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
device_backend_callback error path always says "unable to disconnect",
but this can also happen during the connection of a device. Fix the
error message using the information in aodev->action.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@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>
We pass be_path to tapdisk_destroy but we've already deleted it so it
fails to read tapdisk-params. However it appears that we need to
destroy the tap device after tearing down xenstore, to avoid the leak
reported by Greg Wettstein in
<201207312141.q6VLfJje012656@wind.enjellic.com>.
So read the tapdisk-params in the cleanup transaction, before the
remove, and pass that down to destroy_tapdisk instead. tapdisk-params
may of course be NULL if the device isn't a tap device.
There is no need to tear down the tap device from
libxl__initiate_device_remove since this ultimately calls
libxl__device_destroy.
Propagate and log errors from libxl__device_destroy_tapdisk.
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>
To be consistent with the new function naming, rename
libxl__ao_devices to libxl__multidev and all variables aodevs to
multidev.
No functional change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Roger Pau Monne
Wei Liu
George Dunlap
Ian Jackson
Olaf Hering
Ian Campbell
Yang Hongyang
Andrew Cooper
Matthew Daley
Alexandra Sava
David Scott
Matthew Fioravante