From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7AgH-00039A-NE for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:13:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7Afs-0004cq-Ou for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:13:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7Afs-0004bQ-GN for qemu-devel@nongnu.org; Mon, 12 Mar 2012 15:12:52 -0400 Message-ID: <4F5E4AA8.6020200@redhat.com> Date: Mon, 12 Mar 2012 21:12:40 +0200 From: Itamar Heim 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> In-Reply-To: <4F5E4805.1060402@codemonkey.ws> 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: Anthony Liguori Cc: Gleb Natapov , libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Jiri Denemark , "arch@ovirt.org" On 03/12/2012 09:01 PM, Anthony Liguori wrote: > On 03/12/2012 01:53 PM, Itamar Heim wrote: >> On 03/11/2012 05:33 PM, Anthony Liguori wrote: >>> On 03/11/2012 09:56 AM, Gleb Natapov wrote: >>>> On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote: >>>>> -cpu best wouldn't solve this. You need a read/write configuration >>>>> file where QEMU probes the available CPU and records it to be used >>>>> for the lifetime of the VM. >>>> That what I thought too, but this shouldn't be the case (Avi's idea). >>>> We need two things: 1) CPU model config should be per machine type. >>>> 2) QEMU should refuse to start if it cannot create cpu exactly as >>>> specified by model config. >>> >>> This would either mean: >>> >>> A. pc-1.1 uses -cpu best with a fixed mask for 1.1 >>> >>> B. pc-1.1 hardcodes Westmere or some other family >>> >>> (A) would imply a different CPU if you moved the machine from one system >>> to another. I would think this would be very problematic from a user's >>> perspective. >>> >>> (B) would imply that we had to choose the least common denominator which >>> is essentially what we do today with qemu64. If you want to just switch >>> qemu64 to Conroe, I don't think that's a huge difference from what we >>> have today. >>> >>>>> It's a discussion about how we handle this up and down the stack. >>>>> >>>>> The question is who should define and manage CPU compatibility. >>>>> Right now QEMU does to a certain degree, libvirt discards this and >>>>> does it's own thing, and VDSM/ovirt-engine assume that we're >>>>> providing something and has built a UI around it. >>>> If we want QEMU to be usable without management layer then QEMU should >>>> provide stable CPU models. Stable in a sense that qemu, kernel or CPU >>>> upgrade does not change what guest sees. >>> >>> We do this today by exposing -cpu qemu64 by default. If all you're >>> advocating is doing -cpu Conroe by default, that's fine. >>> >>> But I fail to see where this fits into the larger discussion here. The >>> problem to solve is: I want to use the largest possible subset of CPU >>> features available uniformly throughout my datacenter. >>> >>> QEMU and libvirt have single node views so they cannot solve this >>> problem on their own. Whether that subset is a generic Westmere-like >>> processor that never existed IRL or a specific Westmere processor seems >>> like a decision that should be made by the datacenter level manager with >>> the node level view. >>> >>> If I have a homogeneous environments of Xeon 7540, I would probably like >>> to see a Xeon 7540 in my guest. Doesn't it make sense to enable the >>> management tool to make this decision? >> >> literally, or in capabilities? >> literally means you want to allow passing the cpu name to be exposed >> to the guest? > > Yes, literally. > > Xen exposes the host CPUID to the guest for PV. Both PHYP (IBM System P) > and z/VM (IBM System Z) do the same. > > What does VMware expose to guests by default? > >> if in capabilities, how would it differ from choosing the correct "cpu >> family"? >> it wouldn't really be identical (say, number of cores/sockets and no >> VT for time >> being) > > 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. 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. > >> 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".