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:51:00 -0700 Message-ID: <4FD23B84.8060404@hp.com> References: <1339173966.26976.95.camel@ul30vt> <4FD23221.5090208@hp.com> Reply-To: chegu_vinod@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alex Williamson , kvm@vger.kernel.org To: chegu_vinod@hp.com Return-path: Received: from g4t0014.houston.hp.com ([15.201.24.17]:25704 "EHLO g4t0014.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762282Ab2FHRvc (ORCPT ); Fri, 8 Jun 2012 13:51:32 -0400 In-Reply-To: <4FD23221.5090208@hp.com> Sender: kvm-owner@vger.kernel.org List-ID: On 6/8/2012 10:10 AM, Chegu Vinod wrote: > 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.... Currently the host and the guest are using udev version 147. Host seemed to boot ok with 3.4.1 kernel and this version of udev... but the guest is the one that has these problems... Wondering if any others have observed similar problems ? If yes...Did updating the udev to a more recent version solve it ? Any clues/pointers are appreciated... Thanks Vinod > > > Vinod > >> >> Alex >> >