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
From d1e18afbf5bbab08c9f05e5c9a235cd5e6037822 Mon Sep 17 00:00:00 2001 From: Christian Seiler <christ...@iwakd.de> Date: Mon, 7 Mar 2016 11:21:45 +0100 Subject: [PATCH] Make semantics of /dev/baseimage a bit clearer in manpage. --- virt-subproc/adt-virt-qemu.1 | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/virt-subproc/adt-virt-qemu.1 b/virt-subproc/adt-virt-qemu.1 index ea8ef21..2124b2c 100644 --- a/virt-subproc/adt-virt-qemu.1 +++ b/virt-subproc/adt-virt-qemu.1 @@ -29,7 +29,11 @@ primary image, and add all other images as read-only. The first image without the overlay is always added as an additional read-only hard drive, which will be available for tests as .IR /dev/baseimage . -This allows tests that require nested VMs to reuse the same image. +This allows tests that require nested VMs to reuse the same image. Be +aware that the image will not be accessible during reboots of the +testbed; before requesting a reboot of the testbed, all access to this +image should cease and may be resumed only after test execution +continues. .SH REQUIREMENTS .B adt-virt-qemu -- 2.1.4
signature.asc
Description: OpenPGP digital signature
