IMO, you should refactor your test. If regression test needs as long as 6 hours to complete, the test itself is a problem.
A simple and intuitive approach is to split the test cases into multiple groups, and run the groups in parallel on different servers/VMs On Thu, Jul 31, 2014 at 6:09 AM, Tony Su <ton...@su-networking.com> wrote: > If your main objective is performance, I don't think that there is > any question you should be considering LXC to eliminate overhead. > The reason why LXC is the ultimate in performance is because the > Guests run in a bare metal environment, resources are not virtualized > but simply isolated from other "Guests." and the Host. > > QEMU provides features others don't, primarily various emulation but > there is a cost to that. > Paravirtualization (ie implementing KVM) is important but still exacts > a small price compared to LXC. > > Tony > > On Wed, Jul 30, 2014 at 9:06 AM, Dale R. Worley <wor...@alum.mit.edu> > wrote: > >> From: chester tinemas <chester.tine...@gmail.com> > >> > >> I am trying to increase the speed at which a guest runs in Qemu, so > that I > >> can run a regression test on software within the guest OS in a shorter > >> amount of time. Hopefully this would allow a test that would take 6 > hours > >> normally take less when run inside qemu. Is this possible using qemu or > >> other software, I've had a look into operators such as -icount but this > >> doesn't seem to be exactly what I'm looking for. > > > > The first step is to ensure that Qemu is using KVM so that the bulk of > > the guest's instructions are executed directly by the hardware. > > > > Of course, Qemu has overheads, so the guest will never run as fast in > > Qemu as it would if it was running directly on the hardware. > > > > If I understand you correctly, you want to make the guest run faster > > than it would if it ran on hardware. The only way to do that is to > > have Qemu itself running on hardware that is much faster than the > > hardware the guest normally runs on. > > > > Dale > > > >
