In our upcoming hypervisor comparison, we look at Hyper-V, Xen (Citrix and Novell) and ESX. So far KVM has got lot of press (in the OS community), but I have yet to see anything KVM in a production environment. We are open to suggestions, but it seems that we should give priority to the 3 hypervisors mentioned and look at KVM later.
It is only now, June 2009, that Redhat announces a "beta-virtualization" product based on KVM. When running many VMs on a hypervisor, robustness and reliability is by far the most important criteria, and it seems to us that KVM is not there yet. Opinions (based on some good observations, not purely opinions :-) ?
Something that is becoming more important as higher I/O systems are virtualized is disk alignment. Make sure your guest OS's are aligned with the SAN blocks.
I'd like to second this point. Mis-alignment of physical blocks with virtual blocks can result in two or more physical disk operations for a single VM operation. It's a quick way to kill I/O performance!
Actually, I'd like to see an in-depth article on SANs. It seems like a technology space that has been evolving rapidly over the past several years, but doesn't get a lot of coverage.
We are definitely working on that. Currently Dell and EMC have shown interest. Right now we are trying to finish off the low power server (and server CPUs) comparison and the quad socket comparison. After a the summer break (mid august) we'll focus on a SAN comparison.
I personally have not seen any test on SANs. Most sites that cover it seem to repeat press releases...but I have may have missed some. It is of course a pretty hard thing to do as some of this stuff is costing 40k and more. We'll focus on the more affordable SANs :-).
Some linux systems using the 2.6 kernel make 10x as many interrupts as Windows?
Can you be more specific? Does it matter which specific 2.6 kernel you're using? Does it matter what filesystem you're using? Why do they do that? Can they be configured to behave differently?
The way you've said it, it's like a blanket FUD statement that you shouldn't use Linux. I'm used to higher standards than that on Anandtech.
As yknott already clarified, this is not in any way meant to be a jab at Linux, but is in fact a real problem caused by the gradual evolution of the Linux kernel. Sure enough, fixes have been implemented by now, and I will make sure to have that clarified in the article.
Now that I've read the whitepaper, and looked at the kernel revisions in question, it seems that only people who don't update their kernel should worry about this.
Based on a little search and a wikipedia entry, it appears that only Red Hat (or the major distros) is still on the older kernel version.
Technically Linux is NOT tickless, dynaticks only mean that when there are no interrupts occurring and the cpu is idle, there are no timer interrupts fired. When the CPU is in use, tick interrupts are still fired at 1000hz.
To your point, this is still a huge advantage when it comes to virtualization. Most of the time CPUs are idle and not having the underlying VM hypervisor process ticks from each VM that is idle will allow for more processing power for the VMs who DO need the CPU time.
I also agree that RedHat definitely needs to keep up with the kernel patches. I understand that there is some lag due to regression testing etc, but two years seems a bit much.
I think what Liz was talking about has to do with the tick interrupt under Linux. Since the 2.6.x kernel, this was set to a default of 1000hz or 1000 times a second.
I don't believe you shouldn't use linux, as you can change this tick rate either in the kernel or at boot time. For example, under RHEL 5, just set divider=10 in your boot options to get a 100hz tick rate.
Liz, while that paragraph makes sense, perhaps it doesnt tell the whole story about tick rate and interrupts under vmware. While I agree that running at a lower tickrate is ideal, perhaps mentioning that the interrupt rate is adjustable on most OSes.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
13 Comments
Back to Article
vorgusa - Monday, June 29, 2009 - link
Just out of curiosity will you guys be adding KVM to the list?JohanAnandtech - Wednesday, July 1, 2009 - link
In our upcoming hypervisor comparison, we look at Hyper-V, Xen (Citrix and Novell) and ESX. So far KVM has got lot of press (in the OS community), but I have yet to see anything KVM in a production environment. We are open to suggestions, but it seems that we should give priority to the 3 hypervisors mentioned and look at KVM later.It is only now, June 2009, that Redhat announces a "beta-virtualization" product based on KVM. When running many VMs on a hypervisor, robustness and reliability is by far the most important criteria, and it seems to us that KVM is not there yet. Opinions (based on some good observations, not purely opinions :-) ?
Grudin - Monday, June 29, 2009 - link
Something that is becoming more important as higher I/O systems are virtualized is disk alignment. Make sure your guest OS's are aligned with the SAN blocks.yknott - Monday, June 29, 2009 - link
I'd like to second this point. Mis-alignment of physical blocks with virtual blocks can result in two or more physical disk operations for a single VM operation. It's a quick way to kill I/O performance!thornburg - Monday, June 29, 2009 - link
Actually, I'd like to see an in-depth article on SANs. It seems like a technology space that has been evolving rapidly over the past several years, but doesn't get a lot of coverage.JohanAnandtech - Wednesday, July 1, 2009 - link
We are definitely working on that. Currently Dell and EMC have shown interest. Right now we are trying to finish off the low power server (and server CPUs) comparison and the quad socket comparison. After a the summer break (mid august) we'll focus on a SAN comparison.I personally have not seen any test on SANs. Most sites that cover it seem to repeat press releases...but I have may have missed some. It is of course a pretty hard thing to do as some of this stuff is costing 40k and more. We'll focus on the more affordable SANs :-).
thornburg - Monday, June 29, 2009 - link
Some linux systems using the 2.6 kernel make 10x as many interrupts as Windows?Can you be more specific? Does it matter which specific 2.6 kernel you're using? Does it matter what filesystem you're using? Why do they do that? Can they be configured to behave differently?
The way you've said it, it's like a blanket FUD statement that you shouldn't use Linux. I'm used to higher standards than that on Anandtech.
LizVD - Monday, June 29, 2009 - link
As yknott already clarified, this is not in any way meant to be a jab at Linux, but is in fact a real problem caused by the gradual evolution of the Linux kernel. Sure enough, fixes have been implemented by now, and I will make sure to have that clarified in the article.If white papers aren't your thing, you could have a look at http://communities.vmware.com/docs/DOC-3580">http://communities.vmware.com/docs/DOC-3580 for more info on this issue.
thornburg - Monday, June 29, 2009 - link
Thanks, both of you.thornburg - Monday, June 29, 2009 - link
Now that I've read the whitepaper, and looked at the kernel revisions in question, it seems that only people who don't update their kernel should worry about this.Based on a little search and a wikipedia entry, it appears that only Red Hat (or the major distros) is still on the older kernel version.
zdzichu - Tuesday, June 30, 2009 - link
True, for for quite some time Linux is tickless and doesn't generate uneeded timer interrupts. This change went into 2.6.21, which was released TWO YEARS ago. http://kernelnewbies.org/Linux_2_6_21#head-8547911...">http://kernelnewbies.org/Linux_2_6_21#h...47911895...yknott - Tuesday, June 30, 2009 - link
Technically Linux is NOT tickless, dynaticks only mean that when there are no interrupts occurring and the cpu is idle, there are no timer interrupts fired. When the CPU is in use, tick interrupts are still fired at 1000hz.To your point, this is still a huge advantage when it comes to virtualization. Most of the time CPUs are idle and not having the underlying VM hypervisor process ticks from each VM that is idle will allow for more processing power for the VMs who DO need the CPU time.
I also agree that RedHat definitely needs to keep up with the kernel patches. I understand that there is some lag due to regression testing etc, but two years seems a bit much.
yknott - Monday, June 29, 2009 - link
Thornburg,I think what Liz was talking about has to do with the tick interrupt under Linux. Since the 2.6.x kernel, this was set to a default of 1000hz or 1000 times a second.
I don't believe you shouldn't use linux, as you can change this tick rate either in the kernel or at boot time. For example, under RHEL 5, just set divider=10 in your boot options to get a 100hz tick rate.
You can read more about this on VMware's timekeeping article here: http://www.vmware.com/pdf/vmware_timekeeping.pdf">http://www.vmware.com/pdf/vmware_timekeeping.pdf
Checkout page 11/12 for more info.
Liz, while that paragraph makes sense, perhaps it doesnt tell the whole story about tick rate and interrupts under vmware. While I agree that running at a lower tickrate is ideal, perhaps mentioning that the interrupt rate is adjustable on most OSes.