Description of problem:
I believe this should be a documentation bug but wasn't sure what to open it under.
The manual install guide for RH OSP5 does not specifically talk about the virt_type parameter for nova.conf, and by default is qemu when following this setup method. On all-in-one or nested/VM deployments this is ok or even preferred, but for running a production multi-node non-nested deployment, kvm virt_type should be used, should it not?
This is not referenced anywhere in the current docs, could result in a less-than-optimal production deployment. We experienced a considerable performance increase with instances when this was switched to the kvm virt_type (and installing the relevant libvirt kvm packages)
Version-Release number of selected component (if applicable):
Reassigning to Summer Long, who is in charge of all Compute content.
Joe, usage of the virt_type parameter (and, by extension, Hypervisors config) is explained better in:
We'll look into how we can highlight that content better. Thanks!
Two quick add'l points to make though:
1. I think people will by default first follow the installation guide, which goes into a lot of other choice detail/tradeoffs on other topics like which MQ and which DB to use, but I would consider the use of KVM vs QEMU a far more important decision to make. I expect a good portion of people will deploy following only the configuration guide and leave a lot at default, which will drop them into an inefficient deployment.
2. The configuration reference guide link you provided actually references:
KVM is configured as the default hypervisor for Compute.
To enable KVM explicitly, add the following configuration options to the /etc/nova/nova.conf file:
But -- the default that gets explicitly set in the nova.conf file by the RH OSP5 nova package installs via yum actually sets the virt_type = qemu
I think this will get missed in either or both documents and result in a sub-par installation. A lot of customers are starting up POCs of RH OSP now (we're helping a few) and this could result in a lower-performing RH OSP stack vs what is getting deployed via other distributions...
Just my 2 cents :)
I did a basic manual install of Compute, and it didn't reset the virt_type away from kvm. Perhaps the package has been updated since you last tried an install?
My version is: openstack-nova-compute-2014.1.1-4.el7ost.noarch
For RHELOSP-Installer deployments (production env), was told that the config would be set to the best defaults for whatever component combinations were given. So that shouldn't be an issue either.
On the other hand, the PackStack install did reset to qemu. Because PackStack is intended for PoC environments, and a look-ma-no-hands installation, asking customers to futz with low-level config isn't ideal. Perhaps I should raise a bug to get the PackStack folk to take out the qemu change? Is there any good reason to stay with qemu?
thanks for your patience, Summer
Am setting this to ON_QA; Don, does this sound right to you? Close this and ask dev for a PackStack change?
I will run through another compute node build with the latest package versions and see if it has changed. I was not using packstack or any other deployment tools.
[root@osp5-comptest ~]# grep "virt_type=" /etc/nova/nova.conf
It looks like the parameter is now defined as KVM in 1.2-1 but still commented. So, it is better, but I would take it a step further and uncomment this in the default config.
Up to you guys though, hope this helps!
Thanks Joe. The commented-out value is the default, so that will work for the user. Or are you saying that you want the comment removed so that the KVM value is made explicit and obvious?
Leaving on QA, waiting for Joe's reply.
Joe looks to have moved on. Closing, the default is KVM.