Bug#842299: autopkgtest-virt-qemu: attaching base image makes btrfs very confused

[Christian Seiler]

(Subscribing to the bug report, but feel free to keep me in Cc
anyway.)

On 10/30/2016 04:52 PM, Martin Pitt wrote:
> Or perhaps there is some way how the base image could be a bit
> obfuscated/hidden from the kernel/udev? (I can't think of any which
> are cheap and not an utter/unrelibale hack).

Well, one could do the following before attaching the base image
(pseudo-code, untested):

if [ -e /lib/udev/rules.d/64-btrfs.rules ] ; then
  echo 'KERNEL=="vd*", ENV{ID_SERIAL}=="BASEIMAGE", goto="btrfs_skip_baseimage"' > /etc/udev/rules.d/64-btrfs.rules
  cat /lib/udev/rules.d/64-btrfs.rules >> /etc/udev/rules.d/64-btrfs.rules
  echo 'LABEL="btrfs_skip_baseimage"' >> /etc/udev/rules.d/64-btrfs.rules
fi

That would hopefully solve the problem for btrfs at least.

It's a real shame that udev's last_rule is gone... (But I
probably said that in the initial bug report as well.)

>> For least-astonishment, the default should perhaps be to *not* provide
>> the base image as a block device (and tests that need to exercise
>> nested virtualization can specifically ask for it), but that would be
>> a behaviour change so I haven't done it in the attached patch.
> 
> I don't think this is widely used yet -- I think Christian's
> open-iscsi tests are probably the only ones.

As far as I know that's the case.

> I never saw an "official"
> Debian/Ubuntu autopkgtest fail due to that, and this feature is
> limited to the QEMU runner, which isn't being used on Debian's and
> Ubuntu's testing infrastructure.

Yes - though I'd really like to see QEMU tests integrated in the future
in DebCI (haven't had time to bring it up though) but only run them for
all isolation-machine tests.

> In other words, I think that providing an option for this and default
> to off might be safer and not actually break compatibility
> unacceptably hard. IIRC Christian's original patches back then even
> did provide this as an option, I just didn't see a reason for it back
> then as it's negligible overhead to provide.
> 
> Christian, what's your opinion on this?

Well, regardless of whether this is going to be made optional, the main
problem here is that it doesn't work with btrfs. Let's think a couple
of years into the future, and perhaps btrfs is the default filesystem
by then. In that case, even autopkgtest images will be created with
btrfs by default - and then I wouldn't be able to test open-iscsi with
it.

What I really don't want to do is to have to create a special image for
open-iscsi. I use the autopkgtest QEMU image on my system for testing
all sorts of packages, open-iscsi being only one of them. Also, just
because I'm the only one that's implemented nested tests so far doesn't
mean they are that special. I think they could be _very_ useful for
the testing of early-boot stuff in a lot of packages. And while I
initially did indeed suggest it as an optional feature, after my long
discussions with Martin I've come to think that having this on by
default is the better solution.

I'd also be open to investigating whether we could export the image
via a custom 9p filesystem handler (that will just be a single
directory with a single file in it). As Debian/Ubuntu kernels support
9p out of the box, this should work - writing the 9p handler on the
outside of the virtualization is going to be a bit more difficult, but
should be doable. I'd be willing to work on that. That way, we don't
have to deal with udev / block devices / this kind of automatic magic
at all.

We could then do the following:

 - I test the above hack with the udev rules to work around the
   immediate problem so that Simon can use btrfs-based adt images.
   A new version of autopkgtest is uploaded with that change.

 - This bug is kept open until I can come up with an implementation
   that doesn't use QEMU disk drives anymore but a custom 9p fs
   handler. That way, we will never run into the same kind of
   problem again in the future and bypass all udev/kernel etc.
   logic. Performance would likely suffer a tiny bit, but not too
   badly I hope.

Would that be agreeable to both of you?

Regards,
Christian