qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Tokarev <mjt@tls.msk.ru>,
	gollub@b1-systems.de, Michael@gnu.org,
	"Richard W.M. Jones" <rjones@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Buildbot for qemu.git/master
Date: Tue, 08 Feb 2011 00:36:16 -0200	[thread overview]
Message-ID: <1297132576.2738.22.camel@freedom> (raw)
In-Reply-To: <AANLkTinaeC2-7fmWu4AdqJtXCvOtfvN8NYdLqgz40Mv3@mail.gmail.com>

On Mon, 2011-02-07 at 15:15 +0000, Stefan Hajnoczi wrote:
> On Mon, Feb 7, 2011 at 3:02 PM, Richard W.M. Jones <rjones@redhat.com> wrote:
> >
> > On Sat, Feb 05, 2011 at 04:36:11PM +0000, Stefan Hajnoczi wrote:
> >> Occassionally a commit that breaks the build gets merged into
> >> qemu.git/master.  Build testing manually across all host platforms is
> >> not feasible for most developers.  Remember we cover 32- and 64-bit
> >> x86 Linux, Windows, and other host platforms.  There are factors like
> >> compile time but the main problem is that few have access to all host
> >> platforms.
> >
> > Is there a plan to test that the build minimally functions as well?
> > Could be as simple as running:
> >
> > ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
> >  -kernel /boot/vmlinuz -nodefconfig -nographic -nodefaults -no-reboot \
> >  -m 500 -device virtio-serial -serial stdio -append 'panic=1 console=ttyS0'
> >
> > and just checking that it doesn't hang and does print out some
> > expected message near the end ("Kernel panic - not syncing: VFS:
> > Unable to mount root fs" might be a good one :-)
> 
> I'm not aware of a plan but if someone steps up with tests and
> machines that can serve as buildslaves, then the infrastructure can
> support it.
> 
> I believe KVM-Autotest does that and much more for KVM x86 but have
> never run it myself:
> http://www.linux-kvm.org/page/KVM-Autotest

Yes, it is, our current sanity jobs are much more comprehensive than
what was described. They currently:

* Install guests (RHEL6 and Win7 these days) on a number of option
scenarios (virtio, ide, large memory pages, etc)
* Boot them, making sure they are alive by performing remote login on
the guests
* Verify the hardware seen by the guest OS matches what we provided on
the command line
* Shut down the guests

Of course, we have other types of functional jobs, but just illustrating
what the framework can do today. It is possible to:

* Install a specific kernel build on the guest
* Choose what version of qemu user space to use for the testing

And we have some functionality to provision hosts using cobbler, that
will be sent upstream soon. It's a lot of automation infrastructure at
our service.

      reply	other threads:[~2011-02-08  2:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-05 16:36 [Qemu-devel] Buildbot for qemu.git/master Stefan Hajnoczi
2011-02-05 20:32 ` [Qemu-devel] " Stefan Hajnoczi
2011-02-07 13:00   ` Alexander Graf
2011-02-07 14:36     ` Stefan Hajnoczi
2011-02-07 14:44       ` Alexander Graf
2011-02-07 15:26         ` Stefan Hajnoczi
2011-02-08  2:29       ` Lucas Meneghel Rodrigues
2011-02-08  9:23         ` Stefan Hajnoczi
2011-02-08 11:23           ` Lucas Meneghel Rodrigues
2011-02-08 11:26             ` Alexander Graf
2011-02-08 11:28             ` Stefan Hajnoczi
2011-02-08 12:32               ` Alexander Graf
2011-02-07 19:03   ` Luiz Capitulino
2011-02-07 21:18     ` Stefan Hajnoczi
2011-02-07 21:23       ` Alexander Graf
2011-02-07  8:30 ` Daniel Gollub
2011-02-07  9:34   ` Stefan Hajnoczi
2011-02-08 11:14     ` Daniel Gollub
2011-02-08 11:39       ` Stefan Hajnoczi
2011-02-07 15:02 ` [Qemu-devel] " Richard W.M. Jones
2011-02-07 15:15   ` Stefan Hajnoczi
2011-02-08  2:36     ` Lucas Meneghel Rodrigues [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1297132576.2738.22.camel@freedom \
    --to=lmr@redhat.com \
    --cc=Michael@gnu.org \
    --cc=gollub@b1-systems.de \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).