<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>High Avaiability on myvirtualcloud.net</title><link>https://myvirtualcloud.net/tags/high-avaiability/</link><description>Recent content in High Avaiability on myvirtualcloud.net</description><generator>Hugo</generator><language>en-us</language><copyright>Andre Leibovici</copyright><lastBuildDate>Sat, 12 Sep 2009 09:21:00 +0000</lastBuildDate><atom:link href="https://myvirtualcloud.net/tags/high-avaiability/index.xml" rel="self" type="application/rss+xml"/><item><title>VMware View Higher Levels of Availability</title><link>https://myvirtualcloud.net/vmware-view-higher-levels-of-availability/</link><pubDate>Sat, 12 Sep 2009 09:21:00 +0000</pubDate><guid>https://myvirtualcloud.net/vmware-view-higher-levels-of-availability/</guid><description>&lt;p&gt;I have been working with VMware View since version 2.0, and I have to admit that VMware has made significant improvements on version 3.1.&lt;/p&gt;&#10;&lt;p&gt;The Connection Broker availability has always been a point of discussion so VMware released a replica server mode. It works with ADAM&amp;#160; (Active Directory Application Mode) that is replicated to a secondary server and vice-versa. Despite that will solve the problems for most of the administrators I was imagining how I could improve the design proposed by VMware. &lt;br /&gt; &lt;br /&gt;I am administrating a large VSphere cluster and another small VI3 cluster (only two ESXi hosts). Due to application compatibility VMView had to stay on VI3 and this cluster is now dedicated to VMView as everything else has already been migrated to VSphere. (VMware promised compatibility with VSphere until the end of year).&lt;/p&gt;</description></item></channel></rss>