From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeiTE-0004cb-6Y for qemu-devel@nongnu.org; Tue, 21 May 2013 05:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UeiTC-0006ry-F8 for qemu-devel@nongnu.org; Tue, 21 May 2013 05:03:00 -0400 Received: from mail-oa0-f46.google.com ([209.85.219.46]:61775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UeiTC-0006rl-9Z for qemu-devel@nongnu.org; Tue, 21 May 2013 05:02:58 -0400 Received: by mail-oa0-f46.google.com with SMTP id h2so466569oag.19 for ; Tue, 21 May 2013 02:02:57 -0700 (PDT) Message-ID: <519B383B.9010708@gmail.com> Date: Tue, 21 May 2013 17:02:51 +0800 From: Li Zhang MIME-Version: 1.0 References: <519B2E24.40104@gmail.com> <20130521083953.GB31290@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [qemu-devel][libvirt] Default machine type setting for ppc64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: libvir-list@redhat.com, "qemu-devel@nongnu.org" , anthony@codemonkey.ws, Paul Mackerras , Pradipta Kumar Banerjee On 2013年05月21日 16:45, Peter Maydell wrote: > On 21 May 2013 09:39, Daniel P. Berrange wrote: >> Libvirt has always had support for specifying what machine type to use. >> This discussion is simply about what machine type to default to, if the >> user hasn't explicitly asked for one. >> >> QEMU has the notion of a default machine for each target, and that is >> what libvirt uses if the user hasn't specified a machine. It is not >> libvirt's job to override QEMU's notion of the default machine here, > Agreed; thanks for the clarification. > >> so if the 'mac99' machine type isn't suitable as the default either >> QEMU needs to change that for the ppc target, or the user needs to >> explicitly specify their desired machine type. > OK, that makes sense. So is the problem here just configuration > or is it the next layer above libvirt not being configurable? Currently, the next layer above libvirt is not configurable. It is dependent on this default setting. Users also expect to start one VM successfully by default. Thanks. -- Li > (the thing about changing the default is that it obviously breaks > command line compatibility for anybody who was relying on the > old default. So for ARM we're a bit locked in to a default which > is pretty useless for most people.) > > thanks > -- PMM