[libvirt-users] VM Performance using KVM Vs. VMware ESXi
Hi All We are currently testing our product using KVM as the hypervisor. We are not using KVM as a bare-metal hypervisor. We use it on top of a RHEL installation. So basically RHEL acts as our host and using KVM we deploy guests on this system. We have all along tested and shipped our application image for VMware ESXi installations , So this it the first time we are trying our application image on a KVM hypervisor. On this front i have done some tests to find out how our application's response time is when deployed on KVM and then compare it with a VM deployed on VMware ESXi. We have a benchmark test that basically loads the application simulating a load of 100 parallel users logging into the system and downloading reports. These tests basically use a HTTP GET query to load the application VM. In addition to that i have taken care to use the same hardware for both the tests , one with RHEL(Host)+KVM and another with VMware ESXi. All the hardware specifications for both the servers remain the same. The load test also remains the same for testing with both the servers. First observation is that the average response time on the VMware ESXi is : 500 milli-seconds while the application's average response time when deployed using RHEL(Host)+ KVM is : 1050 milli-seconds. The response time of the application when deployed on KVM is twice as much as when it is deployed using VMware ESXi. I did few more tests to find which sub-system on these servers shows varying metrics. First i started with IOZone to find out if there is any mismatch in the speed with which data is read / written to the local disk on the two VMs and found that "Read" speed in the VM that was deployed using RHEL(Host)+KVM was twice as slow as the VM which was deployed using VMware ESXi. For more on IoZone , Please refer : http://www.iozone.org/ more specifically the following IoZone metrics were twice as less when compared to the server running with VMware ESXi: Read Re-read Reverse-Read Stride Read Pread Note: I had run the IoZone tests on the VMs on both the servers. Second observation to be made was the output from the "top" command. I could see that the VM deployed on RHEL(Host)+KVM was showing high numbers for the following metrics when compared with the VM deployed on VMware ESXi: load averages %sy for all the logical processors %si for all the logical processors i debugged further to find out which device is causing more interrupts and found it to be "ide0" , See the output from the /proc/interrupts file below: The other interrupts apart from ide0 are pretty much similar to the VM deployed using VMware ESXi. ************/proc/interrupts ******************* [root@localhost ~]# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 795827 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 65 0 0 0 0 0 0 0 IO-APIC-edge i8042 6: 2 0 0 0 0 0 0 0 IO-APIC-edge floppy 8: 0 0 0 0 0 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi 10: 425785 0 0 0 0 0 0 0 IO-APIC-level virtio0, eth0 11: 47 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb1, HDA Intel 12: 730 0 0 0 0 0 0 0 IO-APIC-edge i8042 14: 188086 0 0 0 0 0 0 0 IO-APIC-edge ide0 NMI: 0 0 0 0 0 0 0 0 LOC: 795813 795798 795783 795767 795752 795737 795723 795709 ERR: 0 MIS: 0 ********************************************* Any pointers to improving the response time for the VM for RHEL(Host)+KVM installation would be greatly appreciated. Thanks Jatin
On 4/14/2015 3:52 PM, Jatin Davey wrote:
Hi All
We are currently testing our product using KVM as the hypervisor. We are not using KVM as a bare-metal hypervisor. We use it on top of a RHEL installation. So basically RHEL acts as our host and using KVM we deploy guests on this system.
We have all along tested and shipped our application image for VMware ESXi installations , So this it the first time we are trying our application image on a KVM hypervisor.
On this front i have done some tests to find out how our application's response time is when deployed on KVM and then compare it with a VM deployed on VMware ESXi. We have a benchmark test that basically loads the application simulating a load of 100 parallel users logging into the system and downloading reports. These tests basically use a HTTP GET query to load the application VM. In addition to that i have taken care to use the same hardware for both the tests , one with RHEL(Host)+KVM and another with VMware ESXi. All the hardware specifications for both the servers remain the same. The load test also remains the same for testing with both the servers.
First observation is that the average response time on the VMware ESXi is : 500 milli-seconds while the application's average response time when deployed using RHEL(Host)+ KVM is : 1050 milli-seconds. The response time of the application when deployed on KVM is twice as much as when it is deployed using VMware ESXi.
I did few more tests to find which sub-system on these servers shows varying metrics.
First i started with IOZone to find out if there is any mismatch in the speed with which data is read / written to the local disk on the two VMs and found that "Read" speed in the VM that was deployed using RHEL(Host)+KVM was twice as slow as the VM which was deployed using VMware ESXi.
For more on IoZone , Please refer : http://www.iozone.org/
more specifically the following IoZone metrics were twice as less when compared to the server running with VMware ESXi:
Read Re-read Reverse-Read Stride Read
Pread
Note: I had run the IoZone tests on the VMs on both the servers.
Second observation to be made was the output from the "top" command. I could see that the VM deployed on RHEL(Host)+KVM was showing high numbers for the following metrics when compared with the VM deployed on VMware ESXi:
load averages %sy for all the logical processors %si for all the logical processors
i debugged further to find out which device is causing more interrupts and found it to be "ide0" , See the output from the /proc/interrupts file below: The other interrupts apart from ide0 are pretty much similar to the VM deployed using VMware ESXi.
************/proc/interrupts ******************* [root@localhost ~]# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 795827 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 65 0 0 0 0 0 0 0 IO-APIC-edge i8042 6: 2 0 0 0 0 0 0 0 IO-APIC-edge floppy 8: 0 0 0 0 0 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi 10: 425785 0 0 0 0 0 0 0 IO-APIC-level virtio0, eth0 11: 47 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb1, HDA Intel 12: 730 0 0 0 0 0 0 0 IO-APIC-edge i8042 14: 188086 0 0 0 0 0 0 0 IO-APIC-edge ide0 NMI: 0 0 0 0 0 0 0 0 LOC: 795813 795798 795783 795767 795752 795737 795723 795709 ERR: 0 MIS: 0 *********************************************
Any pointers to improving the response time for the VM for RHEL(Host)+KVM installation would be greatly appreciated.
Thanks Jatin
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users Forgot to provide this information.
We are using RHEL(Host): [root@localhost ~]# cat /etc/*release LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Red Hat Enterprise Linux Server release 6.5 (Santiago) Red Hat Enterprise Linux Server release 6.5 (Santiago) and the Qemu being used is: virsh # version Compiled against library: libvirt 0.10.2 Using library: libvirt 0.10.2 Using API: QEMU 0.10.2 Running hypervisor: QEMU 0.12.1 Thanks Jatin
Dear Jatin, Maybe it’s a good idea first to implement Spice: <video> <model type='qxl' ram='65536' vram='65536' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> Spice should be installed on the host. Do you use virtio ? Greetings, Dominique. Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 12:23 Aan: libvirt-users@redhat.com Onderwerp: [libvirt-users] VM Performance using KVM Vs. VMware ESXi Hi All We are currently testing our product using KVM as the hypervisor. We are not using KVM as a bare-metal hypervisor. We use it on top of a RHEL installation. So basically RHEL acts as our host and using KVM we deploy guests on this system. We have all along tested and shipped our application image for VMware ESXi installations , So this it the first time we are trying our application image on a KVM hypervisor. On this front i have done some tests to find out how our application's response time is when deployed on KVM and then compare it with a VM deployed on VMware ESXi. We have a benchmark test that basically loads the application simulating a load of 100 parallel users logging into the system and downloading reports. These tests basically use a HTTP GET query to load the application VM. In addition to that i have taken care to use the same hardware for both the tests , one with RHEL(Host)+KVM and another with VMware ESXi. All the hardware specifications for both the servers remain the same. The load test also remains the same for testing with both the servers. First observation is that the average response time on the VMware ESXi is : 500 milli-seconds while the application's average response time when deployed using RHEL(Host)+ KVM is : 1050 milli-seconds. The response time of the application when deployed on KVM is twice as much as when it is deployed using VMware ESXi. I did few more tests to find which sub-system on these servers shows varying metrics. First i started with IOZone to find out if there is any mismatch in the speed with which data is read / written to the local disk on the two VMs and found that "Read" speed in the VM that was deployed using RHEL(Host)+KVM was twice as slow as the VM which was deployed using VMware ESXi. For more on IoZone , Please refer : http://www.iozone.org/ more specifically the following IoZone metrics were twice as less when compared to the server running with VMware ESXi: Read Re-read Reverse-Read Stride Read Pread Note: I had run the IoZone tests on the VMs on both the servers. Second observation to be made was the output from the "top" command. I could see that the VM deployed on RHEL(Host)+KVM was showing high numbers for the following metrics when compared with the VM deployed on VMware ESXi: load averages %sy for all the logical processors %si for all the logical processors i debugged further to find out which device is causing more interrupts and found it to be "ide0" , See the output from the /proc/interrupts file below: The other interrupts apart from ide0 are pretty much similar to the VM deployed using VMware ESXi. ************/proc/interrupts ******************* [root@localhost ~]# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 795827 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 65 0 0 0 0 0 0 0 IO-APIC-edge i8042 6: 2 0 0 0 0 0 0 0 IO-APIC-edge floppy 8: 0 0 0 0 0 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi 10: 425785 0 0 0 0 0 0 0 IO-APIC-level virtio0, eth0 11: 47 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb1, HDA Intel 12: 730 0 0 0 0 0 0 0 IO-APIC-edge i8042 14: 188086 0 0 0 0 0 0 0 IO-APIC-edge ide0 NMI: 0 0 0 0 0 0 0 0 LOC: 795813 795798 795783 795767 795752 795737 795723 795709 ERR: 0 MIS: 0 ********************************************* Any pointers to improving the response time for the VM for RHEL(Host)+KVM installation would be greatly appreciated. Thanks Jatin
On 4/14/2015 4:02 PM, Dominique Ramaekers wrote:
Dear Jatin,
Maybe it’s a good idea first to implement Spice:
<video>
<model type='qxl' ram='65536' vram='65536' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
Spice should be installed on the host.
[Jatin] How will using Spice help in improving better response time from a web application that i am using inside a VM ? Can you throw more light in this regard if it helps in improving the response time.
Do you use virtio ?
[Jatin] I am not sure about this. Can you tell me how can i find out if i am using virtio or not ?
Greetings,
Dominique.
Thanks Jatin
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference. About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look… Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 12:44 Aan: Dominique Ramaekers; libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi On 4/14/2015 4:02 PM, Dominique Ramaekers wrote: Dear Jatin, Maybe it’s a good idea first to implement Spice: <video> <model type='qxl' ram='65536' vram='65536' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> Spice should be installed on the host. [Jatin] How will using Spice help in improving better response time from a web application that i am using inside a VM ? Can you throw more light in this regard if it helps in improving the response time. Do you use virtio ? [Jatin] I am not sure about this. Can you tell me how can i find out if i am using virtio or not ? Greetings, Dominique. Thanks Jatin
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM: ******************************** <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit ******** or other application using the libvirt API. --> <domain type='kvm'> <name>******</name> <uuid>********</uuid> <title>*******</title> <description>***********</description> <metadata> <template name="****"> <disks> <location type="local" name="Local" path="/VM_DATA_01"/> <disk> <source file="/opt/am-data/sw-download/apps//****/ovf/****/system.vmdk" format="vmdk"/> <target file="/VM_DATA_01/****/****.qcow2" format="qcow2"/> </disk> </disks> <applications> <application> <name>****</name> <description>****</description> <version>****</version> <icon>****</icon> </application> </applications> </template> </metadata> <memory unit='KiB'>20971520</memory> <currentMemory unit='KiB'>20971520</currentMemory> <vcpu placement='static'>8</vcpu> <os> <type arch='x86_64' machine='rhel6.5.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='en-us' passwd='*****'> <listen type='address' address='0.0.0.0'/> </graphics> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain> ******************************************* Thanks Jatin
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'>
<devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk>
This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
Please read: https://libvirt.org/formatdomain.html -----Oorspronkelijk bericht----- Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 13:39 Aan: Daniel P. Berrange CC: Dominique Ramaekers; libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
Thanks Dominique & Daniel. Looks like i need to upgrade my VMs kernel to make it aware of virtio. Found this information from this link: http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel. Thanks for all the responses and pointers. Thanks Jatin On 4/14/2015 5:08 PM, Dominique Ramaekers wrote:
Please read: https://libvirt.org/formatdomain.html
-----Oorspronkelijk bericht----- Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 13:39 Aan: Daniel P. Berrange CC: Dominique Ramaekers; libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi
On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
On 2015-04-14 14:33, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Unless their kernels are very old, you only need to rebuild your initrd as documented in the wiki (or similarly for other distributions).
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
Thanks for all the responses and pointers.
Thanks Jatin
On 4/14/2015 5:08 PM, Dominique Ramaekers wrote:
Please read: https://libvirt.org/formatdomain.html
-----Oorspronkelijk bericht----- Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 13:39 Aan: Daniel P. Berrange CC: Dominique Ramaekers; libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi
On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
-- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwedas@tao.at | +43 (0)680 301 7167 http://software.tao.at
On 14/04/15 13:33, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
As somebody has already said it would have to be a really old kernel to not handle virtio-block, and it's more likely that your bootloader and/or initrd are confused by sda becoming vda. However if your kernel supports it then virtio-scsi should be even better than virtio-block and shouldn't cause the device name to change. Tom -- Tom Hughes (tom@compton.nu) http://compton.nu/
On 4/14/2015 6:32 PM, Tom Hughes wrote:
On 14/04/15 13:33, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
As somebody has already said it would have to be a really old kernel to not handle virtio-block, and it's more likely that your bootloader and/or initrd are confused by sda becoming vda.
However if your kernel supports it then virtio-scsi should be even better than virtio-block and shouldn't cause the device name to change.
Tom
My VM is using the kernel 2.6.18-164.el5 [root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Should this be fine ? Thanks Jatin
On 14/04/15 14:16, Jatin Davey wrote:
My VM is using the kernel 2.6.18-164.el5
[root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Should this be fine ?
Well it won't have virtio-scsi I'm sure, but what does "modinfo virtio-blk" say about virtio-block? Tom -- Tom Hughes (tom@compton.nu) http://compton.nu/
On 4/14/2015 6:51 PM, Tom Hughes wrote:
On 14/04/15 14:16, Jatin Davey wrote:
My VM is using the kernel 2.6.18-164.el5
[root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Should this be fine ?
Well it won't have virtio-scsi I'm sure, [Jatin] Yes , it does not have virtio-scsi
but what does "modinfo virtio-blk" say about virtio-block? [Jatin] [root@localhost virtio]# modinfo virtio-blk filename: /lib/modules/2.6.18-164.el5/kernel/drivers/block/virtio_blk.ko
[root@localhost virtio]# modinfo virtio-scsi modinfo: could not find module virtio-scsi license: GPL description: Virtio block driver alias: virtio:d00000002v* srcversion: A9DBCDB63CCE543B4BBAF31 depends: virtio vermagic: 2.6.18-164.el5 SMP mod_unload gcc-4.1 module_sig: 883f3504a9f767957f09578a977b7e1121870a0c3c17c4c17a09f4825b9b3add41f93c65bf75ad0a0afa2471b36c74a6c7dedc468dd197c1d9eea86aa
Tom
Thanks Jatin
On 14.04.2015 15:16, Jatin Davey wrote:
On 4/14/2015 6:32 PM, Tom Hughes wrote:
On 14/04/15 13:33, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
As somebody has already said it would have to be a really old kernel to not handle virtio-block, and it's more likely that your bootloader and/or initrd are confused by sda becoming vda.
However if your kernel supports it then virtio-scsi should be even better than virtio-block and shouldn't cause the device name to change.
Tom
My VM is using the kernel 2.6.18-164.el5
[root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Should this be fine ?
Is there any particular reason why you are using RHEL 5? The current version is RHEL 7 which contains much more up-to-date versions of kernel, qemu and other virtualization tools. Regards, Dennis
Is there any particular reason why you are using RHEL 5? The current version is RHEL 7 which contains much more up-to-date versions of kernel, qemu and other virtualization tools.
Regards, Dennis
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
I am looking at upgrading to RHEL 7 or 6.6 but before getting there i want to see if the existing version works fine. If it works then i am good but if it does not then i will have to upgrade to newer versions. Thanks Jatin
On 15.04.2015 05:55, Jatin Davey wrote:
Is there any particular reason why you are using RHEL 5? The current version is RHEL 7 which contains much more up-to-date versions of kernel, qemu and other virtualization tools.
Regards, Dennis
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
I am looking at upgrading to RHEL 7 or 6.6 but before getting there i want to see if the existing version works fine. If it works then i am good but if it does not then i will have to upgrade to newer versions.
You have to test on the system you intend to run in production later or your results are useless. Simply upgrading to 7 might already give you a big boost in performance simply because the virtualization components are *much* more up-to-date. The qemu/kvm components - the heart of the virtualization - on RHEL 5 are positively ancient so I would not expect to get any decent numbers compared to todays standards. Regards, Dennis
Jatin, Using qemu without the virtio scsi and nic drivers is like running vmware with ide disks and e1000 nic instead of LSI disks and vmxnet3 nics, it forces the system to emulate completely different hardware. In linux the virtio drivers are implemented in the kernel, so you either need a new kernel or the virtio kernel modules. I'm not sure which for RHEL5, but I suspect you can get what you need with the kmod-virtio package, then rebuilding the initrd image to load the modules at boot. Keep in mind that sda will change to vda, which on some linux distros requires updates to the bootloader and inittab, but redhat uses filesystem labels if I remember correctly, so it should just work. Please let us know how the benchmarks look after you get virtio working, I'm curious... schu On 4/14/2015 5:33 AM, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
Thanks for all the responses and pointers.
Thanks Jatin
On 4/14/2015 5:08 PM, Dominique Ramaekers wrote:
Please read:https://libvirt.org/formatdomain.html
-----Oorspronkelijk bericht----- Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 13:39 Aan: Daniel P. Berrange CC: Dominique Ramaekers;libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi
On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it's good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you'll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it's in your XML. If you post your XML, we can take a look...
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Hi Jatin, The RedHat documentation on this is extremely helpful. It's so helpful that I use it as a reference on completely different distributions. VMWare does a pretty good job of guiding you and giving you defaults that are sensible. With Libvirt/QEMU/KVM, you need to get an idea of those and enable them yourself. For example, I see that you are using qcow2 files, but if you don't need the features it provides, then using block devices (usually logical volumes in a volume group) directly for VM disks may be significantly faster. It also depends on how caching is configured. The manuals will step you through all of that. Pay special attention to storage, because it's the first bottleneck a lot of applications hit. Check out the manuals under the virtualization section here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/ Specifically: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... Good luck! Nikki On Tue, Apr 14, 2015 at 9:18 AM, Matt Schumacher <matt.s@aptalaska.com> wrote:
Jatin,
Using qemu without the virtio scsi and nic drivers is like running vmware with ide disks and e1000 nic instead of LSI disks and vmxnet3 nics, it forces the system to emulate completely different hardware.
In linux the virtio drivers are implemented in the kernel, so you either need a new kernel or the virtio kernel modules. I'm not sure which for RHEL5, but I suspect you can get what you need with the kmod-virtio package, then rebuilding the initrd image to load the modules at boot.
Keep in mind that sda will change to vda, which on some linux distros requires updates to the bootloader and inittab, but redhat uses filesystem labels if I remember correctly, so it should just work.
Please let us know how the benchmarks look after you get virtio working, I'm curious...
schu
On 4/14/2015 5:33 AM, Jatin Davey wrote:
Thanks Dominique & Daniel.
Looks like i need to upgrade my VMs kernel to make it aware of virtio.
Found this information from this link:
http://wiki.libvirt.org/page/Virtio#Disk_.28block.29_device_driver
I tried without upgrading the Kernel and as soon as i start my VM it got into Kernel Panic. I will try using virtio after upgrading my VMs kernel.
Thanks for all the responses and pointers.
Thanks Jatin
On 4/14/2015 5:08 PM, Dominique Ramaekers wrote:
Please read: https://libvirt.org/formatdomain.html
-----Oorspronkelijk bericht----- Van: Jatin Davey [mailto:jashokda@cisco.com <jashokda@cisco.com>] Verzonden: dinsdag 14 april 2015 13:39 Aan: Daniel P. Berrange CC: Dominique Ramaekers; libvirt-users@redhat.com Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi
On 4/14/2015 4:58 PM, Daniel P. Berrange wrote:
On Tue, Apr 14, 2015 at 04:53:52PM +0530, Jatin Davey wrote:
On 4/14/2015 4:42 PM, Dominique Ramaekers wrote:
About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference.
[Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later.
About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look…
Here is the xml associated with my VM:
******************************** <domain type='kvm'> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk>
This disk is configured to use IDE, so performance of anything that does disk I/O is going to be terrible. You really want to be using virtio.
<interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>
This doesn't have any model listed at all, so it will be falling back to a generic emulated NIC. Again performance of this is likely going to be terrible for anything doing network I/O. You want to be using virtio for this too.
Regards, Daniel
How do i make use of virtio for the both disk and network that you have mentioned above ? Any pointers to it would be helpful.
Thanks Jatin
_______________________________________________ libvirt-users mailing listlibvirt-users@redhat.comhttps://www.redhat.com/mailman/listinfo/libvirt-users
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
-- Nikki VonHollen Goobuntu Team <https://goto.google.com/goobuntu> 540-553-1904
On 4/15/2015 2:21 AM, Nikki VonHollen wrote:
Hi Jatin,
The RedHat documentation on this is extremely helpful. It's so helpful that I use it as a reference on completely different distributions.
VMWare does a pretty good job of guiding you and giving you defaults that are sensible. With Libvirt/QEMU/KVM, you need to get an idea of those and enable them yourself.
For example, I see that you are using qcow2 files, but if you don't need the features it provides, then using block devices (usually logical volumes in a volume group) directly for VM disks may be significantly faster. It also depends on how caching is configured. The manuals will step you through all of that. Pay special attention to storage, because it's the first bottleneck a lot of applications hit.
Check out the manuals under the virtualization section here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/
Specifically: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...
Good luck! Nikki
Sure , Thanks Nikki. I will surely have to dig deep into storage as i can see a clear bottleneck in it. Thanks for the pointers. Regards, Jatin
In your network interface, it’s not discribed which interface to use. So it will use system standard. If I’m not wrong, RHEL uses virtio then… Maybe, it’s still a good idea to put ‘<model type='virtio'/>’ inside the <interface ‘bridge’> section. Daniel beat me to it about the ide-disk (about not using that)… Also don’t use qcow2 for disk-format if you don’t need to. I prefer raw. Qcow2 has a lot of good points but speed isn’t one of them. For everything you can, use virtio. This driver make sure the io-activities goes directly between guest kernel and host kernel without noticeable delay… Van: Jatin Davey [mailto:jashokda@cisco.com] Verzonden: dinsdag 14 april 2015 13:24 Aan: Dominique Ramaekers; libvirt-users@redhat.com<mailto:libvirt-users@redhat.com> Onderwerp: Re: [libvirt-users] VM Performance using KVM Vs. VMware ESXi On 4/14/2015 4:42 PM, Dominique Ramaekers wrote: About Spice: I think it’s good practice to use spice because it improves the performance of the VM in general by improving screen performance. If your VM is constantly displaying output, you’ll probably will notice a difference. [Jatin] Ok, This is not my concern as of now. I will take a look at it sometime later. About virtio: You can see it in the settings. Better yet, it’s in your XML. If you post your XML, we can take a look… Here is the xml associated with my VM: ******************************** <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit ******** or other application using the libvirt API. --> <domain type='kvm'> <name>******</name> <uuid>********</uuid> <title>*******</title> <description>***********</description> <metadata> <template name="****"> <disks> <location type="local" name="Local" path="/VM_DATA_01"/> <disk> <source file="/opt/am-data/sw-download/apps//****/ovf/****/system.vmdk" format="vmdk"/> <target file="/VM_DATA_01/****/****.qcow2" format="qcow2"/> </disk> </disks> <applications> <application> <name>****</name> <description>****</description> <version>****</version> <icon>****</icon> </application> </applications> </template> </metadata> <memory unit='KiB'>20971520</memory> <currentMemory unit='KiB'>20971520</currentMemory> <vcpu placement='static'>8</vcpu> <os> <type arch='x86_64' machine='rhel6.5.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/libvirt/images/****.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:c9:58:c9'/> <source bridge='br332'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='en-us' passwd='*****'> <listen type='address' address='0.0.0.0'/> </graphics> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain> ******************************************* Thanks Jatin
participants (8)
-
Daniel P. Berrange -
Dennis Jacobfeuerborn -
Dominique Ramaekers -
Jatin Davey -
Matt Schumacher -
Nikki VonHollen -
Sven Schwedas -
Tom Hughes