Red Hat Virtualization Architecture

Latest response



This discussion is created as a follow up to the session I gave in Red Hat summit 2012 on RHEV architecture.

In the session I covered the various RHEV components and the interaction between them.

I invite you to use this platform for asking questions, making comments and giving feedback.


The slides to my presentation can be found in -




Hi Livnat


I notice that the libguestfs toolset comes bundled within RHEV Hypervisor.  Are there any plans to integrate some of these tools into RHEV ? For instance virt-v2v and guestfish would both be exceptionally useful from the Manager UI.



Hi Livnat


Another question for you....


In the latest release of 3.0 I noticed that support for hyperthreaded CPU's has been dropped from the hypervisor.

I understand that this was due to some issues with scheduling vCPU's on physical hyperthreaded CPU's.


Do you have any further information regarding this ?

(I expect with will also effect regular KVM servers and clusters with HT enabled hardware?)

Hi Richard,

Yes  we look into using libguestfs going forward, we also see a great value in using it and want to  leverage it's capabilities.

Actually there is a hook in vdsm that uses it today, "fileinject", hooks are not supported, but it is a great mechanism to play around and try features/technologies that are not in a RHEV yet.



Hi Richard,

When you write: 'support for hyperthreaded CPU's has been dropped' I guess you reffer to the hypervisor no longer reporting the HT as part of the number of CPUs, for example if you have hypervisor with two physical sockets, each socket contains 6 core, and HT is enabled, before the fix the hypervisor reported 2*6*2 = 24 and now it will report 2*6=12.


The bug number that required this fix is 785717, I think this is a private bug, so I copied the reasoning from the bug:


"Hyper threading is quite often problematic when the hosts are underutilized, and even in the most optimal conditions, depending on the loads, can provide up to 20-30% performance increase. This is definitely not a 100% perf. increase, despite what the fake core count tells us. HT tries to execute two threads in each core, but it fails more often than not, and in some use cases, it is recommended to leave HT off completely. This is why, a user planning VM CPU allocations will be mislead by seeing a large number of cores, without the clarification that this is actually the number of threads and not cores (note, I'm not even mentioning sockets here)."


There is another bug that is not fixed yet 848729 (sorry again private bug) which requires that the user will be able to control if the hypervisor reports HT or not.


Having said all that I think that the main (if not the only) effect this change has is on the schedulling of the VM. The management is currently choosing a hypervisor to run the VM on and one of the conditions for a hypervisor to be a candidate for running a VM is that it has no less CPUs than defined in the VM.



Hi Livnat


Yep, that's exactly what I was refering to. Thanks very much for the additional insight.

I am one of those that was "..mislead by seeing a large number of cores.....".  In hindsight, I can now see that HT makes no odds to the performance of the hypervisor or more importantly availability of CPU cycles to the resident VM's.

It is indeed jolly annoying that I an unable to view these "private" bugzilla's, even ones that result from my own RFE's !  But I'll take that battle elsewhere.....


Thanks again.

Hi Livnat


That's great news !

The fileinject hook looks useful (;a=tree;f=vdsm_hooks).

Thanks for that.