Bug#800845: autopkgtest: Add support for nested VMs
mpitt at debian.org
Fri Mar 4 12:16:44 UTC 2016
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.
> > 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
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
- d/p/ubuntu/expose-vmx_qemu64cpu.patch: enable nested kvm by default
in qemu64 cpu type.
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
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the autopkgtest-devel