Bug#800845: autopkgtest: Add support for nested VMs

[Christian Seiler]

On 03/07/2016 10:21 AM, Martin Pitt wrote:
> Martin Pitt [2016-03-07  9:27 +0100]:
>> So I'll still look into adding pre-reboot hooks, removing the drive
>> there, and writing the new udev rule into /run/ instead of /etc; this
>> should address the above issues.
> 
> The attached commit does that, and I tested it in a few iterations.
> WDYT?

Seems good to me. It's a bit unintuitive that device_del also
undoes the drive_add bit, but your code is correct.

I've tested this with my open-iscsi nested tests (see my RFC
to pkg-autopkgtest-devel) and it works out of the box. I also
did a bit of testing with --shell and it seems to work just
fine.

I've attached a patch that updates the man page a bit to make
the current semantics you are using clearer.

> However, there's still one major issue left: Despite the
> "readonly=on", one can actually mount /dev/vdb1 in the VM and write
> files into it! This sounds like a QEMU bug (running
> 1:2.5+dfsg-5ubuntu4 here), but as long as that exists this is
> dangerous as this alters your pristine base images. I already tried to
> add the "readonly=on" to the "device_add", but that's just an "unknown
> property". Unfortunately this stuff isn't documented very well..

I get (w/ qemu-system 1:2.5+dfsg-4~bpo8+1) with current git master
(no changes):
mount: /dev/vdb1 is write-protected, mounting read-only

So I can't really reproduce it. :-(

Looking at the changelog of QEMU between Debian and Ubuntu, there's
also nothing there that would affect this - on the Ubuntu side it's
stuff related to CPU flags and defining additional machine types.

Question: what happens if you do a sync() after writing? Does it
really get written or is it just that your kernel doesn't properly
detect the read-only-ness and modifies the page-cache, not
realizing that the subsequent writes will fail? If it's the latter,
since it is documented that it's read-only, I wouldn't consider
that an issue.

If it's the former, there's an easy workaround: keep the readonly
flag regardless, but create another QEMU overlay for the case that
it doesn't work, and throw the overlay away at reboots - that way,
if a guest does write to it, it's their own fault.

(Note that if this really is buggy on your end, this would be a
real problem for additional images specified on the command line,
because those are also added with readonly=on!)

Regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-semantics-of-dev-baseimage-a-bit-clearer-in-man.patch
Type: text/x-diff
Size: 1125 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160307/fd2afe06/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160307/fd2afe06/attachment-0001.sig>