8:10 a.m.
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