Re: [ovirt-users] oVirt on a single server

On Tue, Sep 6, 2016 at 12:17 PM, Christophe TREFOIS < christophe.trefois(a)uni.lu&gt; wrote: > Hi, > > No, I move VMs around with an Export Storage domain. > If you have enough disk and bandwidth, perhaps it makes more sense to set up Gluster as a shared storage? And then just pin VMs to specific hosts, instead of separate DCs, etc.? Y. > All NFS is exported only to the local machine. > > Nothing is “shared” between hosts. But because I want to export VMs, we > use “shared” storage in oVirt instead of “local”. > > Best, > > -- > > Dr Christophe Trefois, Dipl.-Ing. > Technical Specialist / Post-Doc > > UNIVERSITÉ DU LUXEMBOURG > > LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE > Campus Belval | House of Biomedicine > 6, avenue du Swing > L-4367 Belvaux > T: +352 46 66 44 6124 > F: +352 46 66 44 6949 > http://www.uni.lu/lcsb > > > > ---- > This message is confidential and may contain privileged information. > It is intended for the named recipient only. > If you receive it in error please notify me and permanently delete the > original message and any copies. > ---- > > > > > On 06 Sep 2016, at 10:06, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > > > > On Tue, Sep 6, 2016 at 9:53 AM, Christophe TREFOIS > > <christophe.trefois(a)uni.lu&gt; wrote: > >> Personally my use case is that I have 4 machines with different specs > and storage sizing. So I setup four DC with 1 host each. Then I have hosted > engine on one of the hosts. Storage is local shared via NFS so that I can > move VMs around. > > > > Not sure I fully understand. > > > > You use each of the 4 machines for both storage and running VMs? > > And export nfs on each to all the others? > > > > So that if a VM needs more CPU/memory then disk IO, you can move > > it to another machine and hopefully get better performance even > > though the storage is not local? > > > > I admit that it sounds very reasonable, and agree that doing this > > with nfs is easier than with iSCSI. If you don't mind the risk of > > local-nfs-mount locks, fine. As others noted, seems like it's quite > > a low risk. > > > >> > >> At this point we are not interested necessarily in HA. > >> > >> Maybe for you that's the definition of a Dev environment as production > has other attributes than just the type of storage? > > > > Dev or Prod is for you to define :-) > > > > How much time/money do you loose if a machine dies? If a machine > > locks up until someone notices and handles? > > > >> > >> Would be nice to hear your thoughts about this. > > > > As wrote above, sounds reasonable if you understand the risks > > and can live with them. > > > > Looking at the future you might want to check HC: > > > > https://www.ovirt.org/develop/release-management/features/gl > uster/glusterfs-hyperconvergence/ > > > >> > >> Kind regards, > >> Christophe > >> > >> Sent from my iPhone > >> > >>> On 06 Sep 2016, at 08:45, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > >>> > >>> On Tue, Sep 6, 2016 at 12:34 AM, Christophe TREFOIS > >>> <christophe.trefois(a)uni.lu&gt; wrote: > >>>> So basically we need at least 2 nodes to enter the realm of testing > and maintained? > >>> > >>> I think some people occasionally use hosted-engine with local > >>> iSCSI storage on a single machine. AFAIK it's not tested by CI > >>> or often, but patches are welcome - e.g. using lago and > >>> ovirt-system-tests. > >>> > >>> Can you please explain your intentions/requirements? > >>> > >>> Even if it works, oVirt is not designed for single-machine > >>> _production_ use. For that, I think that most people agree that > >>> virt-manager is more suitable. oVirt on a single machine is > >>> usually for testing/demonstration/learning/etc. > >>> > >>>> > >>>> If we’re talking pure oVirt here. > >>>> > >>>> -- > >>>> > >>>> Dr Christophe Trefois, Dipl.-Ing. > >>>> Technical Specialist / Post-Doc > >>>> > >>>> UNIVERSITÉ DU LUXEMBOURG > >>>> > >>>> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE > >>>> Campus Belval | House of Biomedicine > >>>> 6, avenue du Swing > >>>> L-4367 Belvaux > >>>> T: +352 46 66 44 6124 > >>>> F: +352 46 66 44 6949 > >>>> http://www.uni.lu/lcsb > >>>> > >>>> > >>>> > >>>> ---- > >>>> This message is confidential and may contain privileged information. > >>>> It is intended for the named recipient only. > >>>> If you receive it in error please notify me and permanently delete > the original message and any copies. > >>>> ---- > >>>> > >>>> > >>>> > >>>>> On 05 Sep 2016, at 16:31, Fernando Frediani < > fernando.frediani(a)upx.com.br&gt; wrote: > >>>>> > >>>>> Adding Kimchi to oVirt node perhaps may be the easiest option. It > can be pretty useful for many situations and doesn't need such thing like > mounting NFS in localhost. > >>>>> > >>>>> It is not nice to not have a All-in-One stable solution anymore as > this can help with its adoption for later growth. > >>>>> > >>>>> oVirt-Cockpit looks nice and intresting. > >>>>> > >>>>> Fernando > >>>>> > >>>>> > >>>>>> On 05/09/2016 05:18, Barak Korren wrote: > >>>>>>> On 4 September 2016 at 23:45, zero four <zfnoctis(a)gmail.com&gt; > wrote: > >>>>>>> ... > >>>>>>> I understand and acknowledge that oVirt is not targeted towards > homelab > >>>>>>> setups, or at least small homelab setups. However I believe that > having a > >>>>>>> solid configuration for such use cases would be a benefit to the > project as > >>>>>>> a whole. > >>>>>> As others have already mentioned, using the full oVirt with > engine in > >>>>>> a single host scenario can work, but is not currently actively > >>>>>> maintained or tested. > >>>>>> > >>>>>> There are other options originating from the oVirt community > however. > >>>>>> > >>>>>> One notable option is to use the Cockpit-oVirt plugin [1] which can > >>>>>> use VDSM to manage VMs on a single host. > >>>>>> > >>>>>> Another option is to use the Kimchi project [2] for which > discussion > >>>>>> for making it an oVirt project had taken part in the past [3]. It > >>>>>> seems that also some work for inclusion in oVirt node was also > planned > >>>>>> at some point [4]. > >>>>>> > >>>>>> [1]: http://www.ovirt.org/develop/release-management/features/coc > kpit/ > >>>>>> [2]: https://github.com/kimchi-project/kimchi > >>>>>> [3]: http://lists.ovirt.org/pipermail/board/2013-July/000921.html > >>>>>> [4]: http://www.ovirt.org/develop/release-management/features/nod > e/kimchiplugin/ > >>>>> > >>>>> _______________________________________________ > >>>>> Users mailing list > >>>>> Users(a)ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users(a)ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>> > >>> > >>> > >>> -- > >>> Didi > > > > > > > > -- > > Didi > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users