WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] major slow down with xen implementation

Geoffrey wrote:
Ross S. W. Walker wrote:
Geoffrey wrote:
Todd Deshane wrote:
On Thu, Sep 25, 2008 at 11:57 AM, Geoffrey <lists@xxxxxxxxxxxxxxxxxxxxx> wrote:
Is this a reasonable expectation with virtualization?
This doesn't seem quite right to me, try kernbench and
also make sure the versions of xen and guest kernels
are the same on the server and laptop for a good
comparision.
I'm not running xen on the laptop.  Laptop is RHEL 5.2,
kernel: 2.6.18-92.1.10.el5

The overhead of Xen PV should be pretty low vs native.
I was wrong when I said we were para-virtualizing, this is full virtualization.

Well, why not put up the xen config for the domU and see if
anybody can suggest some tweaks, but if you are using RH + Xen
it would be silly NOT to para-virtualize it.

Can't para-virtualize. Running 64bit on the hardware so as to get access to the full 32GB memory. Running 32bit virtuals, because we have a third party app that won't run on 64bit. I know...
So? Where is the problem? Check your Xen Caps [1] to confirm, that you can run 32bit para-virtualized domU. This is running without problems here: 64bit ubuntu dom0 and 32bit para domU ubuntu / debian.

Greetz Age_M

[1] xm info | grep xen_caps
If the result shows xen-3.0-x86_32p is means you could run 32bit paravirtualized domUs


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users