[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#800845: autopkgtest: Add support for nested VMs



Hi,

replying to IRC:

> <pitti> chris_se: I think the setup should go into adt-virt-qemu, not setup-testbed
> <pitti> setup-testbed is used for lxc or openstack instances too
> <pitti> and it's not a strict requirement to run it
> <pitti> chris_se: but I'm fine with mopping this up myself
> <pitti> chris_se: i. e. install the rule and call udevadm trigger to run it
> <pitti> so that it works without rebooting

So yes, I think you're right that it's better for adt-virt-qemu to
configure this, but I think we can even do it better:

 - DON'T add the drive to the qemu command
 - create the rule
 - udevadm control -R (because otherwise we might fall in the 3s
   window where udev doesn't reload the config)
 - update-initramfs -k all -u (to support reboots)
 - use qemu's monitor to add the drive

This way, the wrong symlinks will never be created (because the
drive won't exist at initial boot without the udev rule) and we can
guarantee that this doesn't cause any weird problems.

I've created a patch that does just that and tested it: with
setup-testbed from current git master it properly installs the udev
rule, *then* adds the drive, and we have:

 - /dev/baseimage exists
 - /dev/disk/by-{part,}uuid/* don't point to the baseimage disk.

Patch is attached.

Would still like to hear a comment about the CPU issue.

Regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-adt-virt-qemu-Implement-support-for-nested-base-imag.patch
Type: text/x-diff
Size: 4495 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20160303/ca71b504/attachment.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/20160303/ca71b504/attachment.sig>


Reply to: