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 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
