I ran RHEV in production in a previous job to give you an idea its
similar to VMWare vSphere. It allows you to have a single host manage
you virtualization environment including live migrations. in addition
it can monitors the virtual machines and hardware so if vms crash
unexpectedly due to hardware failures it can relaunch them on a
different host, but it requires the management host to have access to
ILO's, DRAC's, or similar device to control the power switches of the
servers and the use of SAN or NAS storage to fully work correctly. it
can also manage Gluster storage clusters, however it assumes that the
Gluster clusters are dedicated to RHEV for use by the virtual machines
and nothing else.
there are two features vShpere has that Ovirt does not
1) last I worked with it there was no virtual switch option although I
know there is at least a plan to integrate openvswitch in the future.
2) it can not bring a VM back online in the identical running state if
the hardware crashed, VMware does this by mirroring the ram to a
ramdisk on the SAN the developers of Ovirt consider this to be an edge
case that is often misused, and I think they are right. it slows down
writes to the VM's ram significantly and eats the cache on the SAN
slowing down every thing else on it.
Ovirt is the upstream project.
there is one main difference between ovirt and RHEV, with RHEV you can
use a striped down appliance image on the servers running the VM's,
the appliance is tiny just a few hundred MB and unless its in
maintenance mode (all of the VM's have been automatically migrated off
of it and the management console has temporarily removed it from the
pool of usable servers) it runs with most of volumes mounted as
readonly including the one where it stores its configs so its
considerably hardened. in fact I've run the whole thing off a bootable
SD card slot on a motherboard before in an HP DL385 with no drives or
raid controller. I just loaded it with 8 core CPU's, lots of ram and a
high quality SD card in the slot on the motherboard and it was good to
go.
For storage I suggest using NFS, Gluster (with a minimum of 3 node for
quorum), or a SAN also keep in mind NFS is required for ISO image
storage, and data center migrations. while iSCSI is supported I don't
recommend using it because last I worked with it it had some nasty
race conditions which can stop the system from working until you dig
deep into the database to fix it. Red Hats support can not help you
with it if that happens they say just to drop the database and reload
from backups. that said I have fixed it before by manually deleting
the frozen tasks from the table and triggering the plsql command to
release the lock but it took me a an hour or two to figure it out and
the only reason I was able to is I use to be a PostgreSQL DBA and
could read and understand the PSQL procedures.
On a side note if you are looking at RHEV and Cloudforms its also a
good idea to look at cloudinit as well.


On Sat, Aug 27, 2016 at 10:01 AM, Steven Miano <[log in to unmask]> wrote:
> The upstream of CloudForms is actually: http://manageiq.org/
>
> On Sat, Aug 27, 2016 at 6:16 AM, David Sommerseth
> <[log in to unmask]> wrote:
>>
>> On 27/08/16 09:23, ToddAndMargo wrote:
>> > Hi All,
>> >
>> > Will we be seeing any of this?
>> >
>> >
>> > http://www.infoworld.com/article/3111908/virtualization/red-hat-virtualization-4-woos-vmware-faithful.html
>> >
>> >
>> > And does it have anything to do with qemu-kvm?
>> >
>>
>> AFAIK, Red Hat Virtualization (RHV) is building upon libvirt and
>> qemu-kvm.  The difference is that it comes with a far more powerful
>> management tool than virsh and virt-manager and the host OS is a scaled
>> down RHEL installation fine-tuned for being a virtualization host.
>>
>> Right now I've forgotten what the upstream project of RHV is named, but
>> it should exist such a project.
>>
>> You also have CloudForms, which is an even wider scoped management tool
>> capable of managing more than just libvirt/qemu-kvm virt hosts.  The
>> upstream project for this is called oVirt, IIRC.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>
>
>
>
> --
> Miano, Steven M.
> http://stevenmiano.com