From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chegu Vinod Subject: Re: Large sized guest taking for ever to boot... Date: Fri, 08 Jun 2012 10:10:57 -0700 Message-ID: <4FD23221.5090208@hp.com> References: <1339173966.26976.95.camel@ul30vt> Reply-To: chegu_vinod@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Alex Williamson Return-path: Received: from g1t0029.austin.hp.com ([15.216.28.36]:30285 "EHLO g1t0029.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753859Ab2FHRL2 (ORCPT ); Fri, 8 Jun 2012 13:11:28 -0400 In-Reply-To: <1339173966.26976.95.camel@ul30vt> Sender: kvm-owner@vger.kernel.org List-ID: On 6/8/2012 9:46 AM, Alex Williamson wrote: > On Fri, 2012-06-08 at 16:29 +0000, Chegu Vinod wrote: >> Hello, >> >> I picked up a recent version of the qemu (1.0.92 with some fixes) and tried it >> on x86_64 server (with host and the guest running 3.4.1 kernel). BTW, I observe the same thing if i were to use 1.1.50 version of the qemu... not sure if this is really related to qemu... >> >> While trying to boot a large guest (80 vcpus + 512GB) I observed that the guest >> took for ever to boot up... ~1 hr or even more. [This wasn't the case when I >> was using RHEL 6.x related bits] > Was either case using device assignment? Device assignment will map and > pin each page of guest memory before startup, which can be a noticeable > pause on smallish (<16GB) guests. That should be linear scaling though > and if you're using qemu and not qemu-kvm, not related. Thanks, I don't have any device assignment at this point . Yes I am using qemu (not qemu-kvm)... The issue seems very basic... 'was earlier running RHEL6.3 RC1 on the host and the guest and the host and the guest seemed to boot fine.. Then I switched both the host and the guest to use 3.4.1 kernel (and the recent qemu). udevd is unhappy... Perhaps the existing udevd is incompatible with 3.4.1 kernel or doesn't like something in the pre-existing "database" of devices.... Vinod > > Alex >