qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] About the light VM solution!


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] About the light VM solution!
Date: Tue, 5 Dec 2017 12:06:23 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

On Tue, Dec 05, 2017 at 02:33:13PM +0800, Yang Zhong wrote:
> As you know, AWS has decided to switch to KVM in their clouds. This news make 
> almost all
> china CSPs(clouds service provider) pay more attention on KVM/Qemu, 
> especially light VM
> solution.
> 
> Below are intel solution for light VM, qemu-lite.
> http://events.linuxfoundation.org/sites/events/files/slides/Light%20weight%20virtualization%20with%20QEMU%26KVM_0.pdf
> 
> My question is whether community has some plan to implement light VM or 
> alternative solutions? If no, whether our 
> qemu-lite solution is suitable for upstream again? Many thanks!

Booting VMs faster is appreciated upstream.  I think there is interest
in patches that further this goal and hope you have time to contribute.

What caused a lot of discussion and held back progress was the approach
that was taken.  The basic philosophy seems to be bypassing or
special-casing components in order to avoid slow operations.  This
requires special QEMU, firmware, and/or guest kernel binaries and causes
extra work for the management stack, distributions, and testers.  It is
preferrable to have just one binary and no special configuration
settings.

I think patches are more likely to be merged with the following
approach:
1. Benchmark or profile to find slow operations.
2. Perform an experiment to see if bypassing the operations improves
   performance.  If no, go back to step 1.
3. Investigate the slow operation to see if it can be optimized or
   skipped completely based on run-time knowledge.  This means no
   special '-lite' binaries or new config options.
4. Implement patches to do this, retest, and send them upstream.

My view is that qemu-lite only got to Step 2 in some cases.  Going to
Step 4 is more work but the result will be easier to merge.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]