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

Bug#719215: autopkgtest: please create an autopkgtest-kvmlvm package

On Thu, 21 Nov 2013 08:30:15 +0100 Martin Pitt wrote:

> retitle 719215 please create a QEMU virtualization server
> thanks
> Hello Francesco,

Hello Martin,
thanks for your reply.

> Francesco Poli (wintermute) [2013-08-09 12:26 +0200]:
> > I think that it would be useful to have a binary package to
> > set up a KVM-based virtualized environment for tests.
> > That is to say, something similar to autopkgtest-xenlvm,
> > but based on KVM in stead of Xen, if I understand correcly.
> It should be called adt-virt-qemu, as it doesn't really require KVM;
> with Qemu you could e. g. create an ARM VM and run it on x86 with
> qemu-system, so we need to make the adt-virt-qemu flexible enough to
> allow that.

Fair enough.

It should be equally easy to use KVM behind QEMU, whenever possible
(same architecture for the host and guest system, KVM virtualization
support, ...), though.
I suppose you were implicitly saying this.

> As qemu/qemu-image already support snapshotting, there is little point
> in adding the overhead of LVM, so I drop that part of your feature
> request. I took the liberty to retitle the report accordingly.

That's absolutely fine with me.

> > It seems to me that there's something for Ubuntu using KVM:
> > https://launchpad.net/auto-package-testing
> Indeed, that are our initial scripts to wrap adt-run and virt-null in
> KVM. This has some shortcomings however: It's quite a lot of extra
> code, requires autopkgtest to be installed *in* the VM, and most
> importantly does not support "revert" (snapshotting), so it cannot run
> multiple "breaks-testbed" tests. It would indeed be better to create a
> proper qemu runner and then dramatically simplify the
> auto-package-testing scripts.
> We can take a lot of knowledge from these scripts, as they already
> figured out how to set up and control ephemeral VMs in a robust and
> efficient manner. We must get along with fewer assumptions about the
> nature of the VM though.

It looks like a plan.   ;-)
Is it going to happen soonish?

 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20131124/80857f85/attachment.sig>

Reply to: