From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7BHK-0003Zp-CO for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:51:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7BHI-0006D2-5a for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:51:33 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:55869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7BHH-0006Cf-VS for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:51:32 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Mar 2012 13:51:27 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 85F1A1FF0047 for ; Mon, 12 Mar 2012 13:50:57 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2CJocDF141926 for ; Mon, 12 Mar 2012 13:50:42 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2CJoYxW021309 for ; Mon, 12 Mar 2012 13:50:34 -0600 Message-ID: <4F5E5371.1080300@us.ibm.com> Date: Mon, 12 Mar 2012 14:50:09 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20111218095816.GG21664@redhat.com> <20120309205652.GA6807@otherpad.lan.raisama.net> <20120309210403.GA2319@redhat.com> <20120310124246.GA4408@redhat.com> <20120310155843.GJ2914@otherpad.lan.raisama.net> <4F5B9C6F.3050705@codemonkey.ws> <20120311132755.GJ17882@redhat.com> <4F5CB2EA.10000@codemonkey.ws> <20120311145655.GK17882@redhat.com> <4F5CC5BB.3070000@codemonkey.ws> <4F5E4615.8020205@redhat.com> <4F5E4805.1060402@codemonkey.ws> <4F5E4AA8.6020200@redhat.com> In-Reply-To: <4F5E4AA8.6020200@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Itamar Heim Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Jiri Denemark , "arch@ovirt.org" On 03/12/2012 02:12 PM, Itamar Heim wrote: > On 03/12/2012 09:01 PM, Anthony Liguori wrote: >> >> It's a trade off. From a RAS perspective, it's helpful to have >> information about the host available in the guest. >> >> If you're already exposing a compatible family, exposing the actual >> processor seems to be worth the extra effort. > > only if the entire cluster is (and will be?) identical cpu. At least in my experience, this isn't unusual. > or if you don't care about live migration i guess, which could be hte case for > clouds, then again, not sure a cloud provider would want to expose the physical > cpu to the tenant. Depends on the type of cloud you're building, I guess. >>> ovirt allows to set "cpu family" per cluster. assume tomorrow it could >>> do it an >>> even more granular way. >>> it could also do it automatically based on subset of flags on all >>> hosts - but >>> would it really make sense to expose a set of capabilities which >>> doesn't exist >>> in the real world (which iiuc, is pretty much aligned with the cpu >>> families?), >>> that users understand? >> >> No, I think the lesson we've learned in QEMU (the hard way) is that >> exposing a CPU that never existed will cause something to break. Often >> times, that something is glibc or GCC which tends to be rather epic in >> terms of failure. > > good to hear - I think this is the important part. > so from that perspective, cpu families sounds the right abstraction for general > use case to me. > for ovirt, could improve on smaller/dynamic subsets of migration domains rather > than current clusters > and sounds like you would want to see "expose host cpu for non migratable > guests, or for identical clusters". Would it be possible to have a "best available" option in oVirt-engine that would assume that all processors are of the same class and fail an attempt to add something that's an older class? I think that most people probably would start with "best available" and then after adding a node fails, revisit the decision and start lowering the minimum CPU family (I'm assuming that it's possible to modify the CPU family over time). From a QEMU perspective, I think that means having per-family CPU options and then Alex's '-cpu best'. But presumably it's also necessary to be able to figure out in virsh capabilities what '-cpu best' would be. Regards, Anthony Liguori > _______________________________________________ > Arch mailing list > Arch@ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch >