could not add rhel host ,does anyone sucess add a rhel host as a hypervisor

Latest response

All rhel angent  rpms  have been installed in rhel6.1 x86_64 ,when  adding the host into HOSTS of rhev managerment console .  the status  show "install failed" . check the event : test platform succeeded .  

failed to install host step:INSTALLER LIB;Details: download failed. pathname could not be resolved (verify computer/domain name)


could any one add rhel host as hypervisor succeed ? 


the address of RHEV Manager.

Make sure that the RHEL machine can resolve RHEV Manager's FQDN and vice verse. The resolution should be both Forward and Reverse.

I have configure the IP and  hostname mapping in /etc/hosts ,  must a dns be configured ?

In order to have a proper setup you need it, not sure though it's for this specific case.

I've tested with RHEV Manager entry removed from the DNS and it does work as long as you do have a DNS entry for RHN (you need it for yum updates) and a proper entry in /etc/hosts for RHEV Manger hostname.


Please note that the entry that you need in there is not, this is the name of your host (hypervisor) according to the log. What you need on the hosts is an entry for the server that you have installed RHEV-Manager on.


Additionally please make sure the firewall is configured correctly both on the host and on the RHEV Manager server.


I would recommend to set up a local NFS server if you can't add entries to your existing NFS, you can do it on the RHEV Manager server and it is very easy. If you search this group you'll find examples  how to do that.

yes ,the dns is required , but /etc/hosts  does also works , any IP/hostname  paires to  hosts file , then add rhel host in rhevm  , down load py  successfully ,    but failed at :

could not  fetch vdsm package  


rpm -qa |grep vdsm   in rhel host




rpm -qa |grep yum





In this case, it would be :


Please reinstall the host with this channel added. Also, after the install ensure that iptables are set in accordance to the guides.


- Anitha

I prefer to use RHEL rather than RHEV-H so that I can perform additional host monitoring (e.g. hardware RAID status using Xymon), and because it gives me much less grief when trying to set up "advanced" networking such as bonded trunking with subordinate 802.1q bridges (including "rhevm", see below).


I have been able to get RHEL hosts working without using the RHEV-M "install" function by adding the vdsm and vdsm-reg package trees from the rhevl-x86_64-server-6-rhevm-3-beta channel on my Satellite server using yum, with the following caveats:


  • The fence-agents package is missing.  Had to lift one from the RHEV 2 channel for RHEL 5 (rhel-x86_64-rhev-mgmt-agent-5) and install this.  All the prereqisites for fence-agents can be found in RHEL6 channels, it's just fence-agents itself that is missing (can someone add this please!).
  • vdsm 4.9-96.1 can't be installed at present because it is dependent on a nonexistent qemu-img (or later) package (latest available revision at the time of this writing is 160 - someone please fix!).  Install and older version instead by specifying the package name in full (e.g. yum install vdsm-4.9-91.el6.x86_64).  See all available version using yum search --showduplicates vdsm.  Since vdsm-reg 4.9-96.1 depends on the broken vdsm 4.9-96.1 you won't be able to install that either, so use the same technique to install vdsm-reg 4.9-91 instead.
  • You must configure a bridge named "rhevm" by some means before doing a service vdsm[-reg] start.  Personally, I just hand-craft /etc/sysconfig/network-scripts/ifcfg-* files and then ifup/ifdown interfaces as required.
  • You must edit /etc/vdsm-reg/vdsm-reg.conf before doing a service vdsm-reg start, changing the vdc_host_port from 443 to 8443 (or whatever) and the vdc_host_name to the name or IP address of your RHEV-M server.

If you do all of the above correctly, the host will appear, awaiting approval, in RHEV Manager immediately after vdsm-reg is started, and can then be added to a cluster and auto-reconfigured by RHEV-M.

I've discovered where the missing qemu-img and fence-agents packages are.  Seems that these have popped up in some new beta channels that previously were empty or nonexistent.  It appears that for RHEV 3 beta 3, Red Hat have split the

rhel-x86_64-server-6-rhevm-3-beta channel into

rhel-x86_64-rhev-mgmt-agent-6-beta (where you'll find fence-agents) and rhel-x86_64-server-6-beta (where you'll find the latest qemu-img).  They've left a broken mess in rhel-x86_64-server-6-rhevm-3-beta, though, which wasn't very nice of them.


Also of interest are new rhel-*-rhev-agent-5-server-beta and rhel-*-rhev-agent-6-server-beta channels, which contain agents for RHEV guests (not to be confused wth *-rhev-mgmt-agent-*, which contain the RHEV hypervisor (host) components).  Maybe at long last we'll get to see RHEL guest IP addresses appearing in RHEV Manager!

These channels have been populated since the beginning of beta, nothing has popped up recently.

I've asked the docs team to improve that part of the install guide to clearly call this out.


The details of the beta channels are here


The rhel-x86_64-server-6-rhevm-3-beta  channel contains RHEV-M components


The rhel-x86_64-rhev-mgmt-agent-6-beta contains the components required for a RHEL hypervisor - the VDSM management agent and some updated RHEL packages requried for RHEV 3 - eg. libvirt, qemu-kvm


Can you give me some details of the broken mess you mentioned?


Okay, I think I see what has been going on here.  The rhevm channel contains vdsm and vdsm-reg components, but these are/were presumably only here for deployment to hosts via SSH by RHEV-M as part of a GUI activated "install" procedure.  It was only a fluke that this channel happened to contain an almost-self-contained consistent state (missing only fence-agents) circa beta1 or beta2 such that I was able to set up RHEL-based RHEV hosts by subscribing to this channel rather than the rhev-mgmt-agent channel.  I should of course have been using the rhev-mgmt-agent channel instead.


As it currently stands, it is true that the latest vdsm package in the rhevm channel is dependent on a qemu-img package that isn't in the channel (hence my "broken mess" comments), but since you're not supposed to install hypervisors from this channel to begin with this is pretty irrelevant.


One wonders, though, why vdsm and vdsm-reg are in the rhevm channel at all, if all that RHEV-M is doing is triggering a "yum install" action on the hypervisor (which is supposed to already be subscribed to the rhev-mgmt-agent channel).  Perhaps there are some RPMs here left over from earlier in the beta that could now be removed to avoid confusion?


Thanks for the documentation improvements, this will help.

indeed - rhev-m actually only uses the vdsm-bootstrap rpm to configure vdsm on rhel hosts.

the other rpms are being deployed via yum install only on the machine, not via rhev-m.

we'll check about removing the other vdsm rpms from this channel to avoid confusion.

There's user error and usability error, this sounds like the latter.


The docs improvements should clear things up,  but we take the point that you were confused by seeing the package there, which was there because of some legacy reasons. We'll remove to make it clearer.


Thanks for the continuing feedback.