06.02.2014 17:06, Martijn Grendelman пишет: IMHO, great plus for RHEV is vendor support (it's related not only to RedHat products). If you can spend days in troubleshooting - stay with ovirt. But sometimes it is not acceptable for business. I don't see any other reason.

Hi, On 02/06/2014 04:06 PM, Martijn Grendelman wrote: I suspect you'll get a different answer if you ask here vs Red Hat sales. I'll try to be objective (disclosure: I work for Red Hat). If you are running any applications which are certified on RHEL, and you want to ensure you continue getting the benefits of certification, then you should check if your supplier will support the configuration of "application on RHEL guest on oVirt managed hypervisor" - Red Hat does not support the operating system in this configuration, so if certified applications and support are important, this is something you may want to consider. In general, oVirt will get less integration testing and QA than RHEV (purely a resource allocation issue), so you will occasionally hit bugs in oVirt that are fixed in the equivalent RHEV release. Bug fixes for RHEV get into oVirt too, but in the master branch usually, so if you're running a stable release of oVirt, you may still have the issue, unless the fix is back-ported to the stable release branch. On the flip side, features appear first in oVirt, so if there are newer features you really need, you could use them on oVirt. A few months later, they will be available in the RHEV product. Also, while most RHEV documentation will apply to oVirt, that's not always the case. A recent example was the Node quick start documentation, as pointed out by a list member. If you like documentation matching the actual functionality of the project, you can help fix the oVirt documentation. Actually, that's a key differentiator - your ability to engage with the community, help update the wiki, test new features while they're still in design & ensure they fit your needs, are for me the key selling points of the project. If you want something that is supported, on which your apps are certified, and for which you can get good support, and have a reasonable expectation of more stability, RHEV is for you. You also got this from redhat.com - hope I didn't disappoint you. Cheers, Dave. -- Dave Neary, Lyon, France Email: dneary(a)gnome.org / Jabber: nearyd(a)gmail.com Ph: +33 950 71 55 62 / Cell: +33 6 77 01 92 13

Hi Martijn, That's a good question and not too easy to answer. I work as a Solution Architect and my company is selling both - RHEV and oVirt consulting and support. The reason for doing both is, that we want to give users a choice which solution fits better. The main benefits (in my opinion) of RHEV are: - Support with SLAs Red Hat provides support for RHEV with service levels. For oVirt you have to wait until someone of the developers or community members helps you on the mailing list or in IRC (or you buy support from a company with provides it). - Updates for each release for 3 years You receive for all releases (RHEV 3.1, 3.2,...) 3 years of support and updates. oVirt provides bugfix releases for the actual release (so you want get bugfix updates for 3.2 anymore, you have to upgrade to 3.3). For me this is the biggest advantage of RHEV. - Red Hat Knowledge Base Red Hat Knowledge Base is one of the best knowledge bases and it helps you greatly solving issues and gives useful tips. I use the knowledge base a lot and wouldn't want to miss it for any Red Hat product. - Stability RHEV is tested by a qa team and the releases are really stable. oVirt has newer features which are less tested. I upgrade oVirt release only to .1 releases (e.g. 3.2.x -> 3.3.1), not to .0 to avoid issues. - Guest agents Guest agents and RHEV tools are packaged for RHEL and Windows guests and are working fine. When using oVirt you miss some of the functionality of Windows guest tools or have to copy it from different locations. For other os'es it doesn't matter if using RHEV or oVirt. - Application / os support You should consider if your applications and operating systems are supported in oVirt as well. All apps certified for RHEL are certified for RHEV as well. Main benefits of oVirt: - Newest features oVirt gives you the latest and greatest. So it will take some time until this feature is available in RHEV, too (due to testing). - No subscription coasts You don't have to buy subscriptions for an oVirt environment, so it saves money. But on the other hand it can also cost you more money, if you have to spend a lot of time in troubleshooting or with upgrading (especially with possible upgrading issues) or having down times of your environment. It's not too easy to say if you should use RHEV or oVirt. I hope I could help you making a decision with my explanations above. You could also have both - a RHEV setup for production vms and an oVirt setup for development and qa vms. Regards, René On Thu, 2014-02-06 at 16:06 +0100, Martijn Grendelman wrote:

This is a multi-part message in MIME format. --------------090904010808070801010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Nathanaël, Imho you need a lot of manpower to make this happen. You have to remove all Red Hat trademarks if you want to distribute it - this means remove it from RHEV-manager (engine), RHEV-H (node-image) and all Windows tools (e.g. USB policy editor, RHEV tools,...) so you not only need CentOS 6 build servers, but also Windows ones. Next you should have to support each release for 3 years which means in 2 years you maybe have to build packages for 3-6 RHEV releases - again takes a lot of time. Even if you can automate fetching, building and testing you still have to test it manually, too. I'm unsure if someone would do this work. Just speaking for me and the company I work for - RHEV and oVirt is working fine for us, so I wouldn't see much benefit of repackaging RHEV. Contributing to oVirt project with Nagios plugins, presentations, meetups,... makes more sense for us. Again just speaking about us, but I think other companies think in a same way... Regards, René On 07.02.2014 10:33, Nathanaël Blanchet wrote: --------------090904010808070801010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Nathana&euml;l,<br> <br> Imho you need a lot of manpower to make this happen.<br> <br> You have to remove all Red Hat trademarks if you want to distribute it - this means remove it from RHEV-manager (engine), RHEV-H (node-image) and all Windows tools (e.g. USB policy editor, RHEV tools,...) so you not only need CentOS 6 build servers, but also Windows ones.<br> <br> Next you should have to support each release for 3 years which means in 2 years you maybe have to build packages for 3-6 RHEV releases - again takes a lot of time. Even if you can automate fetching, building and testing you still have to test it manually, too.<br> <br> I'm unsure if someone would do this work. Just speaking for me and the company I work for - RHEV and oVirt is working fine for us, so I wouldn't see much benefit of repackaging RHEV. Contributing to oVirt project with Nagios plugins, presentations, meetups,... makes more sense for us. Again just speaking about us, but I think other companies think in a same way...<br> <br> <br> Regards,<br> Ren&eacute;<br> <br> <br> <div class="moz-cite-prefix">On 07.02.2014 10:33, Nathana&euml;l Blanchet wrote:<br> </div> <blockquote cite="mid:52F4A868.7040901@abes.fr" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <font size="-1">Hi everybody, <br> <br> We could consider a third way : why not building RHEV from SRPMs since redhat provides them on <a moz-do-not-send="true" class="moz-txt-link-freetext" href="ftp://ftp.redhat.com/redhat/rhev-m/3.x/SRPMS/">ftp://f... ? this can be a compromise between stability of rhev and ovirt free of charge.<br> I'm surprised that nobody has got this idea before.<br> <br> </font> <div class="moz-cite-prefix">Le 06/02/2014 19:53, Ren&eacute; Koch a &eacute;crit&nbsp;:<br> </div> <blockquote cite="mid:20140206185356.EDA1C1682@mail.linuxland.de" type="cite"> <pre wrap="">Hi Martijn, That's a good question and not too easy to answer. I work as a Solution Architect and my company is selling both - RHEV and oVirt consulting and support. The reason for doing both is, that we want to give users a choice which solution fits better. The main benefits (in my opinion) of RHEV are: - Support with SLAs Red Hat provides support for RHEV with service levels. For oVirt you have to wait until someone of the developers or community members helps you on the mailing list or in IRC (or you buy support from a company with provides it). - Updates for each release for 3 years You receive for all releases (RHEV 3.1, 3.2,...) 3 years of support and updates. oVirt provides bugfix releases for the actual release (so you want get bugfix updates for 3.2 anymore, you have to upgrade to 3.3). For me this is the biggest advantage of RHEV. - Red Hat Knowledge Base Red Hat Knowledge Base is one of the best knowledge bases and it helps you greatly solving issues and gives useful tips. I use the knowledge base a lot and wouldn't want to miss it for any Red Hat product. - Stability RHEV is tested by a qa team and the releases are really stable. oVirt has newer features which are less tested. I upgrade oVirt release only to .1 releases (e.g. 3.2.x -&gt; 3.3.1), not to .0 to avoid issues. - Guest agents Guest agents and RHEV tools are packaged for RHEL and Windows guests and are working fine. When using oVirt you miss some of the functionality of Windows guest tools or have to copy it from different locations. For other os'es it doesn't matter if using RHEV or oVirt. - Application / os support You should consider if your applications and operating systems are supported in oVirt as well. All apps certified for RHEL are certified for RHEV as well. Main benefits of oVirt: - Newest features oVirt gives you the latest and greatest. So it will take some time until this feature is available in RHEV, too (due to testing). - No subscription coasts You don't have to buy subscriptions for an oVirt environment, so it saves money. But on the other hand it can also cost you more money, if you have to spend a lot of time in troubleshooting or with upgrading (especially with possible upgrading issues) or having down times of your environment. It's not too easy to say if you should use RHEV or oVirt. I hope I could help you making a decision with my explanations above. You could also have both - a RHEV setup for production vms and an oVirt setup for development and qa vms. Regards, Ren&eacute; On Thu, 2014-02-06 at 16:06 +0100, Martijn Grendelman wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi, This may be the wrong place to ask, but I'm looking for input to form an opinion on an "oVirt or RHEV" question within my company. I have been running oVirt for about 5 months now, and I'm quite comfortable with its features and maintenance procedures. We are now planning to build a private virtualization cluster for hosting clients' applications as well as our own. Some people in the company are questioning whether we should buy RHEV, but at this point, I can't see the benefits. Can anyone on this list shed a light on when RHEV might be a better choice than oVirt? What are the benefits? The trade-offs? I am looking for pragmatic, real-world things, not marketing mumbo jumbo. That, I can get from redhat.com ;-) Best regards, Martijn. _______________________________________________ Users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://... </pre> </blockquote> <pre wrap=""> _______________________________________________ Users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users@ovirt.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://... </pre> </blockquote> <br> <pre class="moz-signature" cols="72">-- Nathana&euml;l Blanchet Supervision r&eacute;seau P&ocirc;le exploitation et maintenance D&eacute;partement des syst&egrave;mes d'information 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 T&eacute;l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </blockquote> <br> </body> </html> --------------090904010808070801010606--