Bug#800845: autopkgtest: Add support for nested VMs
Hello Christian,
Christian Seiler [2016-03-06 16:29 +0100]:
> But that does NOT mean that the UUID clashes don't happen. From my
> experience testing this, the UUID clashes would result in ~50%
> the time having /dev/disk/by-uuid/XXX being a symlink to /dev/vdb1
> while the other 50% it would be /dev/vda1.
Ah, this would be because on a reboot the drive is already added to
QEMU, so indeed we don't have the same situation.
> Now funnily enough for mounting the root file system in the
> initramfs, this doesn't appear to have any impact whatsoever (not
> sure why, though, haven' investigated that)
The initramfs only mounts the root fs read-only, so it doesn't really
matter which one it picks. But this might indeed clash as soon as the
real userspace takes over and tries to mount it r/w, and that's not
possible with /dev/baseimage. So in order to exploit that we'd need to
run the udev rule before systemd-remount-fs.service.
Also, is it actually safe to add the base image *again* after a reboot
if it already is added? Won't you have two drives then, and
/dev/baseimage randomly points to one of it?
> What you _could_ do is create a flag file in /run and update the reboot
> script to update the initramfs before rebooting if that flag file is
> set - that way only if a reboot is needed will the initramfs be updated
> and hence you optimize for the common case where that's not needed.
That's one way to mitigate this, although it still sucks as it would
run on *every* reboot, and for some tests like systemd that adds up
quickly! -- so, we need a more persistent flag file. We also need that
flag file on the host side to avoid re-adding the drive to the QEMU
monitor again on each reboot.
Maybe a better way to avoid this would be to introduce the concept of
a pre-boot hook in adt-virt-*, which could then simply remove the
drive via the QEMU monitor. Then the next hook_open() would re-add it,
and everyone is happy. :-)
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160306/26f8154d/attachment.sig>
Reply to: