Commodity hardware for storage and virtualization. I wanted to use hosts for storage and virtualization. Two hosts are all I need. But in order to protect data I thought that can go with 3 - using the third one just for data storage and because of that can use a weak CPU. In order not get a productivity penalty the 3rd host needs to have the same CPU as the other two.
>From what i read if the hosts have different generations of CPU models, they use only the features present in all models. Does it relates to instructions only? To be precise X and Y have 2 CPUs. Does it mean that the third host also needs to have 2 CPUs? What will happen if I use just one CPU which have less cores (then each in X and Y) but the same instruction set extensions? On Jun 3, 2015 6:27 PM, "Simone Tiraboschi" <[email protected]> wrote: > > > ----- Original Message ----- > > From: "Kiril L" <[email protected]> > > To: [email protected] > > Sent: Wednesday, June 3, 2015 4:25:30 PM > > Subject: Re: [ovirt-users] Is it a plausible configuration? > > > > On Wed, Jun 3, 2015 at 4:54 PM, Simone Tiraboschi <[email protected]> > > wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Kiril L" <[email protected]> > > >> To: [email protected] > > >> Sent: Wednesday, June 3, 2015 3:32:52 PM > > >> Subject: [ovirt-users] Is it a plausible configuration? > > >> > > >> Would you please tell me if this configuration is doable or there is > > >> something that i am missing? > > >> > > >> I would like to use only two servers (X and Y) for VDI and Gluster > > >> based storage. > > >> Hosted engine for oVirt and replicated volumes between X and Y for the > > >> gluster storage. Is a third machine Z a must? > > > > > > It works also with just two hosts but it's not that safe: a replica-2 > > > GlusterFS volume affected by a split-brain issue could be not > self-healing > > > while with replica-3 you could rely on quorum enforcement just cause > you > > > are using an odd host number. > > > > > > For oVirt 3.6 we are working on > > > > http://www.ovirt.org/Features/Self_Hosted_Engine_Hyper_Converged_Gluster_Support > > > > > > > > >> _______________________________________________ > > >> Users mailing list > > >> [email protected] > > >> http://lists.ovirt.org/mailman/listinfo/users > > >> > > > > I do not like the risk part! In that case will have to wait for a > > third machine then. > > > > So in future there will be something useful for me but i did not get > > it - what exactly will be different between ovirt 3.5 with quoum > > enforcment and ovirt 3.6 with Hyper Converged Gluster Support? > > Using the same piece of commodity hardware for virtualization purposes and > also as a node of your shared storage is the base idea of hyper-converging. > So you are basically trying to manually do what the setup could do for you > in the next release. > Unfortunately I've to add that this path is not the easiest one and there > are a lot of aspect to be carefully configured in order to get a robust and > reliable deployment. > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/users > > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
