From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37573) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiD6o-00059A-U9 for qemu-devel@nongnu.org; Tue, 03 Jan 2012 17:45:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiD6j-0002r2-2N for qemu-devel@nongnu.org; Tue, 03 Jan 2012 17:45:30 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:44721) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiD6i-0002qp-Rz for qemu-devel@nongnu.org; Tue, 03 Jan 2012 17:45:25 -0500 Received: by iagj37 with SMTP id j37so36643863iag.4 for ; Tue, 03 Jan 2012 14:45:23 -0800 (PST) Message-ID: <4F0384FF.8070207@codemonkey.ws> Date: Tue, 03 Jan 2012 16:45:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111219083141.32311.9429.stgit@abhimanyu.in.ibm.com> <20111219112326.GA15090@elte.hu> <87sjke1a53.fsf@abhimanyu.in.ibm.com> <4EF1B85F.7060105@redhat.com> <877h1o9dp7.fsf@linux.vnet.ibm.com> <20111223103620.GD4749@elte.hu> <4EF701C7.9080907@redhat.com> <87vcp4t45p.fsf@linux.vnet.ibm.com> <4EF838BD.60406@redhat.com> <4EFC903C.3030509@redhat.com> <4EFC9277.9040604@codemonkey.ws> <4F003268.90906@redhat.com> <4F032363.5000700@codemonkey.ws> <4F0381CF.30204@redhat.com> In-Reply-To: <4F0381CF.30204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Paolo Bonzini , Avi Kivity , Nikunj A Dadhania , kvm-devel , qemu-devel On 01/03/2012 04:31 PM, Dor Laor wrote: >> We can just set this for pc-1.1. I don't see any real harm in doing that. > > Great, it 'only' took about 3 years from the time it got developed originally by > Uri... Someone just needs to send a patch. >> When using 'guests-pick', we initially present the most compatible >> network model (rtl8139, for instance). We would provide a paravirtual >> channel (guest-agent?) that could be used to enumerate which models were >> available and let guest decide which model to use for the next reboot. >> You could also enable immediate switch over using hot plug. > > If guest uses an agent, it probably has virtio-serial driver and it indicates it > has other virtio ones, otherwise, the agent won't fly Right, but I still you want the ability for the guest to indicate that it would like to use virtio drivers or not. If you think about it, it makes no sense to choose which type of device gets used in the hypervisor. In an ideal world, the guest would just figure out what it wants to see and get that. The same is probably true about most device model properties. rtc clock slew policy is another good example. Instead of trying to figure out what the guest type is, we should just let the guest request device model settings like that. >>> We need to keep on recommending the best profile for virtualization, >>> for Fedora >>> I think it either enterprise-storage and maybe throughput-performance. >> >> I think that's more of a distro. It might be worth referring to in our >> documentation but I'm not sure it's something we can do much about. > > Someone said on the kvm community call today: "no one reads documentation", so > it better be a script. As noted about we do have it in my favorite distribution, > I hoped all distributions gets it. Indeed, "referring to it in our documentation" was a polite way of saying, it's a distro problem :-) The distro should let you choose a profile during installation or something like that. Regards, Anthony Liguori > > >> Regards, >> >> Anthony Liguori >> >>> >>> If we have a such a script, it can call the matching tuned profile >>> instead of >>> tweaking every /sys option. >>> >>>> >>>> Regards, >>>> >>>> Anthony Liguori >>>> >>>>> HTH, >>>>> Dor >>>>> >>>> >>>> >>> >>> >> > >