XEN vm performance

We are running a demo POC of SUSE XEN. my customer is running two virtual machines. They installed SAP on both virtual machines.

Customer found(complain) that both virtual machine are performing slow comparatively(they have done a similar setup/test using ESX 5 with 3x better results).

Though I haven’t got the chance to look into the logs, or monitor(top, vmstat) the server yet, but would appreciate if you guys can please share something that can help me understand the problem or find the reason behind the issue

Our Environment:

XEN Host OS: SLES 11 SP2 x864
HW: HP Proliant DL 380 G6
CPU: two Physical Quad core processors.
Memory: 32 GB
On XEN host server we can see 16 processors when we ran “cat /proc/cpuinfo”

we created two SLES 11 SP1 virtual machines ‘vbox1’ and ‘vbox2’
resources assigned to vbox1
CPU: 6
Mem: 16 GB
HDD: Two disks(each 1 TB)
OS: SLES 11 SP1

resources assigned to vbox2
CPU: 6
Mem: 10 GB
HDD: 1 TB single disk
OS: SLES 11 SP1

Note: All the disks are SATA and attached locally, no SAN or multipathing.

Regards,
Muhammad Sharfuddin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paravirtualized or fully virtualized? How did they determine the
performance of the two systems (exactly… details please)?

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP0NmCAAoJEF+XTK08PnB5fMoP/jBjvLwmrDb9mmFimZ5InIKl
gOMbi8mlw7TuY8XHm1u+4MfDo39TOqWSEeTNL1KStGFWd7yvXLUDKNDuWpen+zqa
yPbBmCaqv9mTh35gpVX2p/DqUwz8YTb8De6yUuNiIW/n3VUuEDsEKYZn3ZnD8XjL
AoOFx4X717AXc9b1Gd9Y0+Wf1luurBKzsgLVGOK1KXG618QajbiceJ05BatEYgJL
8ACykmDPElYq78L1KlmzwIOVzoUgw1oLt4QRxYJegW+Rpqyo8GwBHfU94DgZAQvz
vQQBwGyWiTxiwkteyDvICmwPOBNi6Wiib4sTGzvazwQRooWcFwE+EryJnesgUrs7
bGRTKM375VAD5rhYkQ/R29nAyFlTrweT6QG++H5Ai/W/FHdIomv3NBKcAZjlZoO2
w4/U5tfZtTUTWq6iryqfvcJtDjkDkm07HZIXxYzKu2p3M85wl6651qykaLNUF+Ji
k6Rxievt2/GrpZr4nmlEMviRBGpdPqrpwy1avagZEWiGNThwHufupX3h30W61OYk
vSnTh8CEJooFO+OEQYW+gJnrSjet4n9JYJW2RihcLm5sQCeSXPPN6y3tIJpaSJuw
e5w0onyiZCqEqtLfNNUd2P1kPXJoiI11P3kHYTXPX4otvIGmz9SJPbSBrBjasFQ5
sZ+x+60e+D0Lwq5bCWwj
=EHOl
-----END PGP SIGNATURE-----

[QUOTE=ab;4993]
Paravirtualized or fully virtualized? [/QUOTE]
as the virtual machines are SLES 11 SP1 therefore I am sure that both virtual machines are Paravirtualized.

[QUOTE=ab;4993]
How did they determine the performance of the two systems (exactly… details please)?[/QUOTE]

As per the customer(SAP Guys), whatever they do in SAP e.g taking backup via SAP native tool, uploading data in their SAP system, performing installation of SAP modules etc… i.e in short
their day-to-day SAP related tasks are slower(takes more time to complete) when comparing with ESX.
On same Hard Ware, this customer has created two SLES 11 SP1 virtual machines atop ESX, and with the same SAP modules/setup, and as per them they found that the current(XEN based) is at least 3 time slower(takes more time to complete) then ESX.

One more question here, do you recommend me to mount the /var/lib/xen/images file system with noatime and barrier=0 options ?

With such VM’s and size of the disks I’d opt to give each SLES guest a physical disk rather than file based.

With the setup you are describing this must be done one the local systems disks, so considering limitations of MBR with traditional partitioning: I’d say go with disk assignments based on LVM. Size the LVM volumes appropriately for each SLES guest system and assign the volume as physical connection to the SLES guest servers.

If the used hw raid controller has the option to split the storage up in correctly sized volumes/devices, that would be even better as you can directly assign these as devices without needing to use LVM to manage the guest storage on the host itself.

Hope that is somewhat clear… and in any case it should give the best performance (phy: over file based disks).

-Willem

One more thing… if this is a POC, why SLES 11 SP1 and not SLES 11 SP2 (which has the newer kernel and Xen version)?

Also, have they installed any specific HP controller software? Could be the used storage driver is not optimized or the controller itself does not have a decent cache controller included?

Dear Magic31,

Thanks for your input/suggestions

[QUOTE=Magic31;4998]
With the setup you are describing this must be done one the local systems disks.[/QUOTE]
Yes all the disks are local.

If I got you correctly then you are saying me to create two LV on XEN Host and then assign those LVes to virtual machines, e.g
LV Name: /dev/xenvg/xenimage-vbox1( for vm1)
LV Name: /dev/xenvg/xenimage-vbox2( for vm2)
and then assign the above LVes to the vm. (but it will kill the flexibility)

one question here, creating Logical Volume provides more performance then simply creating two partitions ?, if e.g I create and assign the partitions(rather LV) to vm as:
/dev/cciss/c0d1p3 to vm1
/dev/cciss/c0d1p4 to vm2
so will it be comparatively slow then assigning LV to the vm ?

I am sorry didnt get you properly… can you please provide me a link(url) that I can pass to the HWare guys ?

[QUOTE=Magic31;4998]
One more thing… if this is a POC, why SLES 11 SP1 and not SLES 11 SP2 (which has the newer kernel and Xen version)?[/QUOTE]
XEN host OS: SLES 11 SP2
vm os: SLES 11 SP1
The SAP partner(customer) here is not ready to do this POC atop SLES 11 SP2

Also we mistakenly let the “Create the Sparse Image” file check enabled during the virtual machine (file base disk) creation… would it be a reason/issue only ?
By the way do you think that assigning 6 CPUs to both domU(vm) and only 4 cpus to domain0 is a good idea ? We just assign 6 CPUs when we were creating vm from
virt-manager… i,e we didnt perform the cpu pinning(http://www.suse.com/documentation/sled11/singlehtml/book_xen/book_xen.html#xen.config.cpupinning)… any suggestion on this would again highly appreciated

Regards
Muhammad Sharfuddin

I got the chance to monitor the servers, and and its disk I/O thats the cause of problem.
I found that the virtual machines has full virtual disks(/dev/hdX) rather then paravirtual disks(/dev/xvdX)… I dont know how these virtual machine(SLES 11 SP 1) got the the full virtual disks.
now what should I do ? is there any virtual machine driver pack available for SUSE Linux SP1 ?

Thanks
Muhammad Sharfuddin

[QUOTE=sharfuddin;5079]I got the chance to monitor the servers, and and its disk I/O thats the cause of problem.
I found that the virtual machines has full virtual disks(/dev/hdX) rather then paravirtual disks(/dev/xvdX)… I dont know how these virtual machine(SLES 11 SP 1) got the the full virtual disks.
now what should I do ? is there any virtual machine driver pack available for SUSE Linux SP1 ?

Thanks
Muhammad Sharfuddin[/QUOTE]

Hi Muhammad,

Sorry for my delay in answering to your previous post…

In any case, coming back to your previous post, I meant performance will always be better when using RAW/physical devices for the VM’s… where possible with no to as little as possible management on host/dom0 side.
With local storage using partitions for the domU/guests is not always possible due to partition table limitations and what the hardware (raid controller mainly) will allow you to do in how storage is presented.
Using LVM on the host/dom0 to manage volumes that get handed down to the guests is a means to be able to give the domU’s exactly the mount of storage they need and hand out a volume per guest disk - and LVM does not impose very much management overhead on the host while giving flexibility. One best practice when using LVM for the domUs/guests, is to keep the partitions for the host/dom0 traditional/non LVM.

Long story shot: phy access for the storage of the domU’s should perform (much) better than file based disk’s. And indeed, for production systems creating a sparse file for the disk makes disk performance drop further (with the current methods).

I did not know SAP was not supported (yet) on SLES 11 SP2, in that case SLES 11 SP1 is fine.

There is no VMDP (virtual driver pack) for SLES as it runs paravirtual and all the needed optimizations are in the guest kernel (that’s also running the Xen kernel in guest mode). No extra options should be needed there.

Sometimes it can help to play with the scheduler settings on host and/or guest (choosing the NOOP scheduler for example)… but that depends on your setup and I’ve found with SLES 11 the defaults are already properly tuned.

Getting the SLES domU’s to run on phy connected storage would be the best way to continue the POC. If you have the room try cloning the current domU file based disks to LVM or raw partitions (using tools like dd, partimage, etc).

-Willem

Would you mind placing the plain VM config/or the disk definition section (found in /etc/xen/vm by default) on this forum so we can have a look at what’s been configured?

-Willem

Thanks William for your excellent help

[QUOTE=Magic31;5088]Would you mind placing the plain VM config/or the disk definition section (found in /etc/xen/vm by default) on this forum so we can have a look at what’s been configured?

-Willem[/QUOTE]
here we go

# /etc/xen/vm/BMD
name="BMD"
description="SAP BMD"
uuid="ff7ac85f-8da2-757b-e5f0-f3e4bdf404e6"
memory=18432
maxmem=18432
vcpus=6
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=0
keymap="en-us"
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="c"
disk=[ 'file:/var/lib/xen/images/BMD/disk0.raw,hda,w', 'file:/sles11-sp1.iso,hdc:cdrom,r', ]
vif=[ 'mac=00:16:3e:71:68:53,bridge=br0,type=netfront', ]
stdvga=0
vnc=1
vncunused=1
viridian=0
acpi=1
pae=1
serial="pty"


# /etc/xen/vm/BMD.xml
<domain type='xen'>
  <name>BMD</name>
  <description>SAP BMD</description>
  <uuid>ff7ac85f-8da2-757b-e5f0-f3e4bdf404e6</uuid>
  <memory>18874368</memory>
  <currentMemory>18874368</currentMemory>
  <vcpu>6</vcpu>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <clock sync='utc'/>
  <keymap>en-us</keymap>
  <os>
    <type>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
  </os>
  <features>
    <apic/>
    <acpi/>
    <pae/>
  </features>
  <devices>
    <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
      <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/var/lib/xen/images/BMD/disk0.raw'/>
      <target dev='hda'/>
    </disk>
      <disk type='file' device='cdrom'>
      <driver name='file'/>
      <source file='/sles11-sp1.iso'/>
      <target dev='hdc'/>
      <readonly/>
    </disk>
      <interface type='bridge' model='para'>
        <source bridge='br0'/>
        <mac address='00:16:3e:71:68:53'/>
        <script path='/etc/xen/scripts/vif-bridge'/>
      </interface>
    <graphics type='vnc'/>
  
  </devices>
</domain>

# /etc/xen/vm/BMQ
name="BMQ"
description="BMQ"
uuid="44af24d8-fc5f-07c6-01c1-29634bdd9bd6"
memory=12288
maxmem=12288
vcpus=6
on_poweroff="destroy"
on_reboot="destroy"
on_crash="destroy"
localtime=0
keymap="en-us"
builder="hvm"
device_model="/usr/lib/xen/bin/qemu-dm"
kernel="/usr/lib/xen/boot/hvmloader"
boot="d"
disk=[ 'file:/var/lib/xen/images/BMQ/disk0.raw,hda,w', 'file:/sles11-sp1.iso,hdc:cdrom,r', ]
vif=[ 'mac=00:16:3e:54:37:50,bridge=br0,type=netfront', ]
stdvga=0
vnc=1
vncunused=1
viridian=0
acpi=1
pae=1
serial="pty"

# /etc/xen/vm/BMQ.xml
<domain type='xen'>
  <name>BMQ</name>
  <description>BMQ</description>
  <uuid>44af24d8-fc5f-07c6-01c1-29634bdd9bd6</uuid>
  <memory>12582912</memory>
  <currentMemory>12582912</currentMemory>
  <vcpu>6</vcpu>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <clock sync='utc'/>
  <keymap>en-us</keymap>
  <os>
    <type>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='cdrom'/>
  </os>
  <features>
    <apic/>
    <acpi/>
    <pae/>
  </features>
  <devices>
    <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
      <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/var/lib/xen/images/BMQ/disk0.raw'/>
      <target dev='hda'/>
    </disk>
      <disk type='file' device='cdrom'>
      <driver name='file'/>
      <source file='/sles11-sp1.iso'/>
      <target dev='hdc'/>
      <readonly/>
    </disk>
      <interface type='bridge' model='para'>
        <source bridge='br0'/>
        <mac address='00:16:3e:54:37:50'/>
        <script path='/etc/xen/scripts/vif-bridge'/>
      </interface>
    <graphics type='vnc'/>
  
  </devices>
</domain>

Also I got the following response from Support:

Regards,
Muhammad Sharfuddin

[QUOTE=sharfuddin;5111]Also I got the following response from Support:

[QUOTE]Response from our backline:

The reason why these disks are showing as full virtualization is because the guest was build as Full Virtualization (FV). By default, SLES guests are installed using PV. I can say that the best way now is reinstall this guest using PV. I’ve tested try to convert from FV to PV and it didn’t work. Customer has to reinstall this guest and restore data from backup
[/QUOTE][/QUOTE]

Hi Muhammad,

Indeed, that would be my advice as well, try converting or reinstalling using phy disk for the guests. As the disks are sized at 1TB, reinstalling would seem a quicker way than trying to convirt… on the other hand, depending on guest filesystem and how much data is really in use… a tool like CloneZilla could be a way to clone the disks (directly from disk to disk or via disk > image > disk) to a new physical partition(s) or LVM volume(s) that has been configured as guest disk(s).

Hope that gives the POC you are hoping for (and a little more :slight_smile: )

-Willem