These patches enable cd-rom media changing for an HVM with a linux
stubdom.
v1 didn't support these empty drives. The code came out of OpenXT which
has a hack - null.iso. null.iso is an ISO with no contents. OpenXT
doesn't actually eject the cd-rom, it just inserts null.iso. This patch
set has QEMU present empty media.
The first patch creates an empty file, /run/xen/empty-cdrom.%u, for Phy
drives that are "empty". The place holder simplifies things because the
block scripts don't work for an empty params. Even if the scripts were
modified for that, a stubdom will timeout on startup when the empty
disk/blkback never connects. The empty file works around these issues.
The second patch allows use of Phy backend drives for a cd-rom. This
works for non-stubdom HVMs. Actually special casing stubdoms didn't
work.
The third patch expands the cd-rom changing code to support the stubdom
case.
To change the cd-rom medium, libxl will:
- QMP eject the medium from QEMU
- block-detach the old PV disk
- block-attach the new PV disk
- QMP change the medium to the new PV disk by fdset-id
xl cd-eject follows the above through connecting the new PV disk,
empty-cdrom.%u. It skips the QMP media change. This keeps the xenstore
entries which are needed to identify that a cd-rom drive is present. If
the xenstore entries were removed on eject, libxl wouldn't find the
device (hdc) for a subsequent cd-insert.
The QMP change insert uses fdset-id STUBDOM_FDSET_CD + $disk - 'a'.
That is, hda -> 'a', so
STUBDOM_FDSET_CD + 'a' - 'a' = STUBDOM_FDSET_CD.
For hdc:
STUBDOM_FDSET_CD + 'c' - 'a' = STUBDOM_FDSET_CD + 2.
The stubdom must internally handle adding /dev/xvdc to the appropriate
fdset inside QEMU.
A script like this:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-core/initrdscripts/initramfs-stubdomain/qemu-xvdc-add-fd.sh
Can be called by busybox mdev configured like this:
https://github.com/OpenXT/xenclient-oe/blob/master/recipes-core/busybox/files/mdev.conf
(OpenXT mdev as the hotplug helper works, but with a ~Qubes stubdom, I
had to run mdev as a daemon, mdev -d.)
Linux locks the cd-rom by default? That means the QMP eject commands
fail, but then Linux unlocks. Re-running a second time works. Windows
doesn't do that.
There are spurious messages sometimes like:
libxl: error: libxl_qmp.c:1837:qmp_ev_parse_error_messages: Domain 5:Could not dup FD for /dev/fdset/8002 flags 0: No such file or directory
libxl doesn't know when the stubdom has setup the fdset. Since it gets
those errors, it'll retry adding to the fdset.
Jason Andryuk (3):
libxl: Create empty cdrom file for stubdom
libxl: Allow Phy backend for CDROM devices
libxl: Enable stubdom cdrom changing
docs/misc/stubdom.txt | 16 ++
tools/libs/light/libxl_device.c | 17 +-
tools/libs/light/libxl_disk.c | 345 +++++++++++++++++++++++++++---
tools/libs/light/libxl_domain.c | 4 +
tools/libs/light/libxl_internal.h | 1 +
5 files changed, 344 insertions(+), 39 deletions(-)
--
2.43.0