[ovirt-users] Setting up oVirt for the first time

[Alexander Wels]

On Tuesday, December 01, 2015 05:59:59 PM Gervais de Montbrun wrote:
> Hi All,
> 
> I've done a lot of reading and lots of comparison of different hypervisors
> and tools and have decided that oVirt would be the best option. My initial
> use case is a not too new server that I will setup to run multiple
> development environments for the devs here, but I wanted something that
> will scale out to production as the vm infrastructure, hardware, etc. grows
> here.
> 
> I'll soon have a second server to run my vm's on and want to setup a
> self-hosted engine. I'm trying to find the most recent version of a how-to
> on the same. I found a presentation showing off how much easier it is to do
> this in oVirt 3.6 but can't find the correct docs. I seem to always end up
> with 3.5 or older versions. Can someone point me at a how-to of how to best
> achieve this.
> 
> Also, while I have you all here... :-)
> Is it possible to setup the hypervisor hosts themselves as NFS servers to
> create Storage (I realize that this will play havoc with the HA). We do
> have an NFS server that we will be upgrading to add storage and faster
> drives, but I was thinking that I may be able to use the internal storage
> of the hypervisors themselves as a short term stopgap and then migrate vm's
> to the upgraded NFS server later. Will that even work, or will it break
> somehow?
> 

I saw Simone gave you an answer about Gluster. Here is my DEVELOPMENT setup, 
which has been running for several years like this now. I have some VMs with 
uptime in the 100+ days. I am NOT doing the hosted engine since I develop stuff 
for the engine and it makes no sense for me to have the hosted engine. Here is 
my setup, which is one option, I will outline some other options which might 
be more appropriate for what you are trying to do to:

* Development engine machine. this runs just the engine.
* 2x hosts, which both expose NFS shares for a data domain.
* Each host can see the NFS share of the other host.
* In my engine I have 2 data domains on one data center. One is the master 
domain the other a secondary data domain.

Pros of this setup:
* I can use the storage on both my hosts for VMs.
* I can live migrate VMs between hosts.
* I can storage migrate VMs between data domains.
* Its cheap and easy to setup

Cons of this setup:
* If any host goes down, the entire data center goes down since both hosts 
need to see all the storage. (Well technically only the VMs that are on the 
storage domain that went down will die and all the VMs on the host that went 
down). So this gives many points of failure for the entire thing to come 
crashing down. This is fine for me since its my development environment and 
nothing critical runs on it.
* Its not always clear on which data domain you will want to create a VM but 
again for me its not much of an issue as this is a development environment.


Here are some other possible setups, which I am not sure will work with hosted 
engine as I believe that requires some kind of shared storage. IIRC it will 
need some kind of shared storage, but it will be separate from the normal data 
domain. So lets assume you have hosted engine up and running and are looking 
at ways of using the storage on the host.

Option 1:
Create a local storage data center and add your hosts to that data center.

Pros of this setup:
* VMs are on local storage so should have decent IO.
* If one host goes down it will not affect any of the other hosts.
* Its cheap and easy to setup.

Cons of this setup:
* No live migration
* No storage migration
* Hard to migrate to a different storage solution later.

Option 2:
This is sort of a hybrid between my setup and option 1. Create several shared 
storage data centers, one for each host. Setup your NFS on each host. Add one 
host to each data center and use the NFS share as the data domain.

Pros of this setup:
* VMs are pretty much on local storage, there is some overhead of the NFS 
share, but it still basically local.
* If one host goes down it will not affect any of the other hosts.

Cons of this setup:
* No live migration
* No storage migration
* Hard to migrate to different storage solution later*.

Given your situation with getting some fast NFS storage at a later point, what 
you can do if you take option2. Once you get the new storage, you can easily 
add an import/export domain and export all your VMs to that storage. One you 
have all your VMs on the import/export domain, create a new data center, add 
your hosts, add your shiny new NFS as a data domain, also add the same 
import/export domain, and import all the VMs into the new data domain. Note 
this might also work for option 1 assuming you can attach import/export domain 
to a local storage data center (I have never tried so I don't know).

In 3.5+ I think you can also simply add a new data center, add your hosts, and 
import the data domains from the other data centers (after you disconnected 
them from there), then storage migrate the VMs. Its more or less the same as 
above just a slightly different mechanism.


Given all of this yes its possible, but not recommended for anything but 
messing around with it. The recommended solution is to use shared storage 
separate from your hosts. This gives you live migration and if one host goes 
down it will not affect your other hosts. Of course if your storage goes down, 
you are screwed regardless, but you can use whatever redundancy mechanism you 
have available on the storage to mitigate that. 


Alexander


> Any advice for a new install would be welcome.
> 
> Thank you
> 
> Cheers,
> Gervais