Bug#800845: autopkgtest: Add support for nested VMs

[Martin Pitt]

Hey Christian,

Christian Seiler [2016-03-04 12:54 +0100]:
>  - if x86_64 and default QEMU command:
>     - if vmx in CPU flags:
>          use -cpu kvm64,+vmx,+lahf_lm
>     - else if svm in CPU flags:
>          use -cpu kvm64,+svm,+lahf_lm
>  - otherwise: don't pass -cpu
> 
> That way, you have the same CPU on any hardware, with the exception
> of the vendor-specific VT extensions.
> 
> If you're agreeable to that, I'll prepare a patch.

Sounds great!

> > That said, at least on the machines I tested, nested kvm does work in
> > principle (maybe some subtle bugs) with the default -cpu too.
> 
> No, it doesn't. Nested QEMU does (and hence adt-virt-qemu will run
> now that you merged baseimage support), but the inner QEMU is not
> using KVM then.

It does for me:

ubuntu at autopkgtest:~$ egrep 'model name|flags' /proc/cpuinfo
model name	: QEMU Virtual CPU version 2.4.0
flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_glusood nopl pni
vmx cx16 x2apic popcnt hypervisor lahf_lm tpr_shadow vnmi flexpriority
ept vpid
ubuntu at autopkgtest:~$ lsmod|grep kvm
kvm_intel             172032  0
kvm                   536576  1 kvm_intel
irqbypass              16384  1 kvm
ubuntu at autopkgtest:~$ ls -l /dev/kvm 
crw------- 1 root root 10, 232 Mar  4 13:02 /dev/kvm

> (Unless you have a QEMU that defaults to some other CPU type by
> default OR you explicitly set the CPU type, perhaps in some
> configuration you forgot about.)

Indeed it seems Ubuntu's qemu is modified accordingly
(https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu1):

    - d/p/ubuntu/expose-vmx_qemu64cpu.patch: enable nested kvm by default
      in qemu64 cpu type.

This is

  http://anonscm.debian.org/cgit/pkg-qemu/qemu.git/tree/debian/patches/ubuntu/expose-vmx_qemu64cpu.patch?h=ubuntu-dev

That explains why, sorry for being dense there.

> >> This is a tangent, but wasn't somebody working on qemu testbeds for
> >> the Debian CI?
> > 
> > I'm not aware of that. However, it's more realistic to use the ssh
> > runner with the nova setup script, given that production debci already
> > runs in the cloud. (This won't be able to use this nesting trick,
> > though).
> 
> This is kind of a bummer for me, because I'd really like to have
> continuous integration for actual functionality that relies on
> nested VMs. But in principle qemu should run in the cloud, right?

In most Openstack ones at least, yes. There are other nova-compute
backends like libvirt or lxc, though. Also, debci is running on Amazon
EC2 (which doesn't use Openstack), but I guess it's qemu there anyway.

> So it's only a question of whether it's somehow possible to get
> a working base image in there?

Right. Openstack/EC2 hide this pretty well, so there's no way to get
the base image into the instance directly :-( It's of course possible
to download a public cloud image in the test, but that's much less
convenient.

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/20160304/73c2348e/attachment.sig>