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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
