<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>vbrowncoat Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>vbrowncoat Tracker</description>
    <pubDate>Wed, 15 Nov 2023 08:28:19 GMT</pubDate>
    <dc:date>2023-11-15T08:28:19Z</dc:date>
    <item>
      <title>Re: Windows failover cluster- vsphere replication</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/Windows-failover-cluster-vsphere-replication/m-p/2851415#M3425</link>
      <description>&lt;P&gt;Next time I recommend posting a new thread when you have a new question:&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.vmware.com/en/Site-Recovery-Manager/8.4/com.vmware.srm.admin.doc/GUID-3EBBD9DA-CD14-45BB-9F4F-2C749881B117.html?hWord=N4IghgNiBcIGZgK4QC4AIUHsIFMBOYAdgMY4gC+QA" target="_blank"&gt;https://docs.vmware.com/en/Site-Recovery-Manager/8.4/com.vmware.srm.admin.doc/GUID-3EBBD9DA-CD14-45BB-9F4F-2C749881B117.html?hWord=N4IghgNiBcIGZgK4QC4AIUHsIFMBOYAdgMY4gC+QA&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 07 Jun 2021 21:38:47 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/Windows-failover-cluster-vsphere-replication/m-p/2851415#M3425</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-06-07T21:38:47Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication restore test</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-restore-test/m-p/2845628#M3412</link>
      <description>&lt;P&gt;vSphere Replication doesn't have a non-disruptive testing capability. Without SRM you would need to run a failover/recovery to test.&lt;/P&gt;</description>
      <pubDate>Thu, 06 May 2021 00:14:36 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-restore-test/m-p/2845628#M3412</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-05-06T00:14:36Z</dc:date>
    </item>
    <item>
      <title>Re: SRM: How to manually configure an IP for each protected virtual for the TEST networks</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-How-to-manually-configure-an-IP-for-each-protected-virtual/m-p/2844415#M13831</link>
      <description>&lt;P&gt;That is not correct &lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5310995"&gt;@JoaquinC&lt;/a&gt;&amp;nbsp;- IP customization will happen during planned migration, failover,&amp;nbsp;&lt;STRONG&gt;and test&lt;/STRONG&gt;.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;You are correct about using an isolated network for keeping your test VMs isolated. In the network mapping configuration, you can designate a test network. This test network can either be auto-generated by SRM (a virtual port group with no uplinks - this would mean that VMs wouldn't be able to communicate with VMs on other hosts, or other networks) or a designated network (I would recommend a duplicate of your production network, same routing and same firewall rules, configured so that this duplicate network is isolated from the rest of your environment.).&lt;/P&gt;</description>
      <pubDate>Wed, 28 Apr 2021 20:24:41 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-How-to-manually-configure-an-IP-for-each-protected-virtual/m-p/2844415#M13831</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-28T20:24:41Z</dc:date>
    </item>
    <item>
      <title>Re: SRM/VR 8.4 with mixed major versions of vCenter Server &amp; ESXi (Migration to new platform)</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-VR-8-4-with-mixed-major-versions-of-vCenter-Server-amp-ESXi/m-p/2843981#M13828</link>
      <description>&lt;P&gt;SRM supports running different versions of VC at the different sites (as of 8.1). The interop matrix is correct as to those versions. It has always supported different host versions and you're doing that how I'd recommend (source at lower version than target).&lt;/P&gt;&lt;P&gt;As of 8.4, SRM &amp;amp; VR also support interop with the most recent previous version also (eg. SRM/VR 8.4 will pair/work with SRM/VR 8.3). The key is that the SRM &amp;amp; VR versions within a site must be the same (unless you are in the process of an upgrade)&lt;/P&gt;</description>
      <pubDate>Mon, 26 Apr 2021 22:52:04 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-VR-8-4-with-mixed-major-versions-of-vCenter-Server-amp-ESXi/m-p/2843981#M13828</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-26T22:52:04Z</dc:date>
    </item>
    <item>
      <title>Re: require VM replication sync status report</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/require-VM-replication-sync-status-report/m-p/2843201#M13814</link>
      <description>&lt;P&gt;In SRM 8.4 there are a lot more reporting export options in the UI&lt;/P&gt;</description>
      <pubDate>Wed, 21 Apr 2021 23:46:44 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/require-VM-replication-sync-status-report/m-p/2843201#M13814</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-21T23:46:44Z</dc:date>
    </item>
    <item>
      <title>Re: Calling a powershell script from SRM appliance</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/Calling-a-powershell-script-from-SRM-appliance/m-p/2843200#M13813</link>
      <description>&lt;P&gt;The ways to run powershell as part of a recovery plan are:&lt;BR /&gt;1. Call a script on the appliance (using bash, perl or python) that will call the powershell script on another VM. Ideally this other VM will always be running at the recovery site.&lt;/P&gt;&lt;P&gt;2. Run a script on a recovered VM&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regarding running a script during cleanup, we haven't added this capability yet. It is something we're working on though.&lt;/P&gt;</description>
      <pubDate>Wed, 21 Apr 2021 23:45:24 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/Calling-a-powershell-script-from-SRM-appliance/m-p/2843200#M13813</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-21T23:45:24Z</dc:date>
    </item>
    <item>
      <title>Re: srm vm appliance and 3par sra</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/srm-vm-appliance-and-3par-sra/m-p/2843198#M13812</link>
      <description>&lt;P&gt;I recommend working with HP on this&lt;/P&gt;</description>
      <pubDate>Wed, 21 Apr 2021 23:42:21 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/srm-vm-appliance-and-3par-sra/m-p/2843198#M13812</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-21T23:42:21Z</dc:date>
    </item>
    <item>
      <title>Re: Array Based Replication with Hitachi Storage</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/Array-Based-Replication-with-Hitachi-Storage/m-p/2843194#M13811</link>
      <description>&lt;P&gt;Array-based replication is dependent on the storage array vendor. It is up to them what they support. It requires a compatible storage replication solution at both sites.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 21 Apr 2021 23:10:08 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/Array-Based-Replication-with-Hitachi-Storage/m-p/2843194#M13811</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-21T23:10:08Z</dc:date>
    </item>
    <item>
      <title>Re: deploying vSphere replication on Mgmt / Workload</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/deploying-vSphere-replication-on-Mgmt-Workload/m-p/2840470#M13788</link>
      <description>&lt;P&gt;I'm not able to see the image of the error. Can you provide details?&lt;/P&gt;&lt;P&gt;Just to be clear, VR only supports replicating VMs that are in the same VC that it is connected to.&amp;nbsp;&lt;/P&gt;&lt;P&gt;What are you trying to accomplish?&lt;/P&gt;</description>
      <pubDate>Wed, 07 Apr 2021 17:12:46 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/deploying-vSphere-replication-on-Mgmt-Workload/m-p/2840470#M13788</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-07T17:12:46Z</dc:date>
    </item>
    <item>
      <title>Re: Array Based Replication with Hitachi Storage</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/Array-Based-Replication-with-Hitachi-Storage/m-p/2840462#M13787</link>
      <description>&lt;P&gt;This is a question for Hitachi. They define the requirements for their&amp;nbsp;array-based replication.&lt;/P&gt;</description>
      <pubDate>Wed, 07 Apr 2021 16:36:03 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/Array-Based-Replication-with-Hitachi-Storage/m-p/2840462#M13787</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-07T16:36:03Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication: Deployment practices</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Deployment-practices/m-p/2839476#M3397</link>
      <description>&lt;P&gt;Next time I recommend a new thread for a new question.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Automatic failure detection - yes, it can alert if connection to the other SRM server is lost. It also supports running a recovery plan via API or vRO workflow. I wouldn't recommend doing this though. See:&amp;nbsp;&lt;A href="https://blogs.vmware.com/vsphere/2014/05/automate-failover-with-srm.html" target="_blank"&gt;https://blogs.vmware.com/vsphere/2014/05/automate-failover-with-srm.html&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 01 Apr 2021 23:13:41 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Deployment-practices/m-p/2839476#M3397</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-01T23:13:41Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication Stops at 99% and never finishes ...</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/vSphere-Replication-Stops-at-99-and-never-finishes/m-p/2839475#M13781</link>
      <description>&lt;P&gt;Do you have any kind of network/anti-virus/malware monitoring solution? I've heard of a rare case where there was a file that was placed on VMs to confirm that the monitoring/prevention tool worked (it would detect the file being transmitted and remove it) which then prevented the replication from completing.&lt;/P&gt;&lt;P&gt;Have you tried cloning the VMs in question? Removing them from the domain (I had a situation a long time ago where an AD setting prevented a failover). What about moving the same VMs (or a clone) to a different network?&lt;/P&gt;</description>
      <pubDate>Thu, 01 Apr 2021 23:10:59 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/vSphere-Replication-Stops-at-99-and-never-finishes/m-p/2839475#M13781</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-04-01T23:10:59Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication: Deployment practices</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Deployment-practices/m-p/2839114#M3395</link>
      <description>&lt;P&gt;1.&amp;nbsp;vSphere Replication is dependent on vCenter so if you are concerned about recoverability you may want to think about how you will ensure the availability of VC (or think about having a second one at your recovery site)&lt;/P&gt;&lt;P&gt;2. The traffic flow for VR goes like this: source host (where replicated VM is running) &amp;gt; VR appliance &amp;gt; storage at target site (through host at target site). Given that, it makes the most sense to place the VR appliance (can be either VRMS or VRS) close to the host/storage at the target.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Mar 2021 05:49:34 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Deployment-practices/m-p/2839114#M3395</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-03-31T05:49:34Z</dc:date>
    </item>
    <item>
      <title>Re: Vsphere replication mixing vswitch types</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/Vsphere-replication-mixing-vswitch-types/m-p/2839112#M3394</link>
      <description>&lt;P&gt;When you use VR by itself you have to select the network that you are recovering a VM to when you recover it. There is no issue moving a VM between network types.&amp;nbsp;&lt;/P&gt;&lt;P&gt;If you use SRM with VR you can map networks as part of protecting the VM so that they can be recovered without having to assign networking. With SRM as well there is no issue mapping between different network types (standard switch, vDS, NSX-T, etc).&lt;/P&gt;</description>
      <pubDate>Wed, 31 Mar 2021 05:42:31 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/Vsphere-replication-mixing-vswitch-types/m-p/2839112#M3394</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-03-31T05:42:31Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication 8.4.x OVFTOOL Changes</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-8-4-x-OVFTOOL-Changes/m-p/2839111#M3393</link>
      <description>&lt;P&gt;I'll work to get the docs updated. Thanks for sharing this.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Mar 2021 05:39:20 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-8-4-x-OVFTOOL-Changes/m-p/2839111#M3393</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-03-31T05:39:20Z</dc:date>
    </item>
    <item>
      <title>Re: Validated Design 6.x for SRM</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/Validated-Design-6-x-for-SRM/m-p/2837397#M13772</link>
      <description>&lt;P&gt;VVDs are defined here:&amp;nbsp;&lt;A href="https://www.vmware.com/solutions/software-defined-datacenter/validated-designs.html" target="_blank"&gt;https://www.vmware.com/solutions/software-defined-datacenter/validated-designs.html&lt;/A&gt;&amp;nbsp;- they are not what is supported with VMware solutions, rather they are blueprints for deployment.&lt;/P&gt;&lt;P&gt;Check the VMware interop matrix if you have questions about compatibility across products&amp;nbsp;&lt;A href="https://interopmatrix.vmware.com/#/Interoperability" target="_blank"&gt;https://interopmatrix.vmware.com/#/Interoperability&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 22 Mar 2021 19:00:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/Validated-Design-6-x-for-SRM/m-p/2837397#M13772</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-03-22T19:00:19Z</dc:date>
    </item>
    <item>
      <title>Re: deploying vSphere replication on Mgmt / Workload</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/deploying-vSphere-replication-on-Mgmt-Workload/m-p/2837396#M13771</link>
      <description>&lt;P&gt;VR appliance currently has to be deployed to the VC it is connected to. SRM appliance doesn't have that requirement. Given these restraints, general VCF recommendations/best practices would apply.&lt;/P&gt;</description>
      <pubDate>Mon, 22 Mar 2021 18:53:52 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/deploying-vSphere-replication-on-Mgmt-Workload/m-p/2837396#M13771</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-03-22T18:53:52Z</dc:date>
    </item>
    <item>
      <title>Re: vSphere Replication Status Report</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Status-Report/m-p/2828441#M3356</link>
      <description>&lt;P&gt;As of VR 8.3 you can now export any datagrid within the UI. We're continuing to enhance this capability as well as provide new options.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Feb 2021 15:48:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/vSphere-Replication-Status-Report/m-p/2828441#M3356</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-02-08T15:48:09Z</dc:date>
    </item>
    <item>
      <title>Re: VMs which have disks on two different arrays</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/VMs-which-have-disks-on-two-different-arrays/m-p/2828435#M13737</link>
      <description>&lt;P&gt;I don't have any additional information on this. I suggest contacting DellEMC about it. In my message I was just suggesting that it was possible that RecoverPoint supported this, I don't know that definitively. Generally, SRM doesn't support protecting a VM with disks on more than one array. Because of the way RP works it may be &lt;U&gt;&lt;STRONG&gt;possible&lt;/STRONG&gt;&lt;/U&gt; that it supports this and presents it to SRM such that it appears that all disks are on the same array. I don't know this, it is me hypothesizing.&lt;/P&gt;</description>
      <pubDate>Mon, 08 Feb 2021 15:37:16 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/VMs-which-have-disks-on-two-different-arrays/m-p/2828435#M13737</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2021-02-08T15:37:16Z</dc:date>
    </item>
    <item>
      <title>Re: SRM array based Multi site Configuration with array pair recoverpoint sra</title>
      <link>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-array-based-Multi-site-Configuration-with-array-pair/m-p/2288755#M11234</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;You need to end up with 3 separate pairs of SRM servers, 1 each for the 3 arrays. Then you install the SRA on each and create array-pairs separately on each one. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;See the documentation: &lt;A href="https://docs.vmware.com/en/Site-Recovery-Manager/8.3/com.vmware.srm.install_config.doc/GUID-BC46053B-644C-420B-BC68-B71D450711A5.html" title="https://docs.vmware.com/en/Site-Recovery-Manager/8.3/com.vmware.srm.install_config.doc/GUID-BC46053B-644C-420B-BC68-B71D450711A5.html"&gt;Installing Site Recovery Manager to Use with a Shared Recovery Site&lt;/A&gt; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;And this blog post for details about SRM and multiple sites/pairs: &lt;A href="https://blogs.vmware.com/virtualblocks/2016/07/28/srm-multisite/" title="https://blogs.vmware.com/virtualblocks/2016/07/28/srm-multisite/"&gt;SRM Multi-Site Options - Virtual Blocks&lt;/A&gt; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Keep in mind that the separate SRM instances will not be aware of each other so make sure that there isn't any overlap in what they manage.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It may be that the SRA (which comes from DellEMC) doesn't support having multiple pairs with the same source/target array? I suggest reaching out to DellEMC as well if you can't get this to work. As an alternative you could look at using vSphere Replication which doesn't require SRAs.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 23 Oct 2020 00:26:49 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Site-Recovery-Manager/SRM-array-based-Multi-site-Configuration-with-array-pair/m-p/2288755#M11234</guid>
      <dc:creator>vbrowncoat</dc:creator>
      <dc:date>2020-10-23T00:26:49Z</dc:date>
    </item>
  </channel>
</rss>

