vbrowncoat's Accepted Solutions

You could do that. You could also copy your VMs to an external drive and use that as a seed for the replication.
Hi Luiz, It is not possible to recover vSphere Replication replicated VMs without vCenter. If you need that kind of capability (recover VMs w/o vCenter - inc vCenter) you may want to take a lo... See more...
Hi Luiz, It is not possible to recover vSphere Replication replicated VMs without vCenter. If you need that kind of capability (recover VMs w/o vCenter - inc vCenter) you may want to take a look at VDP (vSphere Data Protection). It is a backup tool that also provides replication and can recover VMs without vCenter. Does this answer your question? Cheers! PS: I thought your english was great, no need to apologize.
Hi, vSphere Replication requires vCenter to function so you can't use VR to protect it as you wouldn't have a way of recovering it, unless it was replicated to another vCenter (in which case it ... See more...
Hi, vSphere Replication requires vCenter to function so you can't use VR to protect it as you wouldn't have a way of recovering it, unless it was replicated to another vCenter (in which case it could be recovered, but only inside of the other vCenter) or if it was managed by another vCenter. If you're looking at the second option, where you have a management vCenter and VR appliance, and within that you have another vCenter, then yes, you could use SRM in this model to protect and failback your internal vCenter. No difference in this functionality between vCA and windows version of vCenter. Regarding your statement: "or is it like AD/SQL/Exchange and in general you shouldn't be using replication or anything of the sort for them." - vSphere Replication supports VSS quiescing - I agree I wouldn't recommend replicating AD (or SQL and Exchange if you can use the built in application level replication) - If you can't though, most modern applications work fine in a crash consistent state (normal VR replication) and the remainder work with VSS Hope this answers your questions
>Based on this, and the lack of the alarm, we can assume that if I brought down one of the hosts in this 2-host cluster, all the VMs would be able to start on the single remaining host, correct? ... See more...
>Based on this, and the lack of the alarm, we can assume that if I brought down one of the hosts in this 2-host cluster, all the VMs would be able to start on the single remaining host, correct? Correct, if one of your hosts crashed or was reset all your VMs would have resources enough to start (no guarantee of performance, just starting/running) >And the alarm I refer to in this thread's title will only get triggered when that 98% goes to 50% or below, correct? There is no alarm. When your CPU or Memory failover capacity reaches 50% admission control will prevent you from powering on another VM >I am still concerned about that resource distribution chart for Memory, though. It looks like I could push it up to 100% on both hosts, and still not push memory failover capacity lower than 50%. I presume this is due to the fact that my VMs don't have reserved memory, so vSphere only counts the minimal amount of memory required to start the VM, and it will depend on swapping and ballooning if all the VMs actually start using all their memory. Correct >So the alarm I'm looking for is one that replicates the resource distribution chart, and alerts when the total unutilized memory in the cluster is less than the total memory of a single host.  Make sense? I'm not aware of an alarm like this. You may be able to find something through google or create something yourself. What about creating reservations for your VMs? Or at least the important ones? That way you can make sure they'll get the resources when they restart. Or if you really wanted you could change the admission control to the dedicated failover host policy? (with what I know of your situation I don't think I'd recommend this, but it would give you what you are asking for). Have you looked at the vRAS fling? VM Resource and Availability Service – VMware Labs This Fling enables you to perform a what-if analysis for host failures on your infrastructure. You can simulate failure of one or more hosts from a cluster (in vSphere) and identify how many: VMs would be safely restarted on different hosts VMs would fail to be restarted on different hosts VMs would experience performance degradation after restarted on a different host With this information, you can better plan the placement and configuration of your infrastructure to reduce downtime of your VMs/Services in case of host failures.
As Martin mentioned in the other thread, VR (and SRM when using VR) requires a working VRMS at the target/recovery site. To clarify your statement it should read: "when you use vsphere replicatio... See more...
As Martin mentioned in the other thread, VR (and SRM when using VR) requires a working VRMS at the target/recovery site. To clarify your statement it should read: "when you use vsphere replication, if you lose the VRMS at your target/recovery site then you cant recover your vms" With SRM this is still an issue, though normally if your production site is impacted this won't impact the VRMS at the recovery site so you'll still be able to recover. Forced recovery is where no operations are attempted on the protected site so it's really for a different use case. Does this answer your question?
Sounds like a cool project. Keep in mind that from an infrastructure standpoint HA and admission control are still trying to solve the same problem, recover VMs from a host or OS failure as quick... See more...
Sounds like a cool project. Keep in mind that from an infrastructure standpoint HA and admission control are still trying to solve the same problem, recover VMs from a host or OS failure as quickly as possible. As an example, if your new cluster has 20 hosts and you want to be able to have a host in maintenance mode and still suffer a host failure and you've decided to use % based admission control policy (this is the default recommendation, I would recommend you evaluate your environment and determine if it is the right option for you), you'll want to set the % at 10%. This will ensure that your cluster has sufficient resources to restart all running VMs. Keep in mind that unless VMs have reservations, HA just reserves capacity to start the VM, there is no guarantee of performance. As far as your target utilization, that depends on the SLAs you are providing and your tolerance for risk. At the last customer I worked for the answers were: 1. We reserved capacity in a cluster such that we could have a host in maintenance mode and still lose a host and have no VMs experience performance degradation 2. vCOps 3. Yes
The documentation is correct. VDPA can only backup physical systems using the SQL, Exchange & Sharepoint agents. There isn't a way to backup a physical file server using VDPA. Does this answer... See more...
The documentation is correct. VDPA can only backup physical systems using the SQL, Exchange & Sharepoint agents. There isn't a way to backup a physical file server using VDPA. Does this answer your question?
It depends, if you are doing it manually (without a tool like SRM) vSphere will not see VMs on replicated datastores and you would have to manually add them to inventory. Here are some more de... See more...
It depends, if you are doing it manually (without a tool like SRM) vSphere will not see VMs on replicated datastores and you would have to manually add them to inventory. Here are some more details: you would have to take a snapshot of the LUN, break the mirror or flip replication the other direction in order to mount the storage to hosts on the DR site. Then you would have to manually add the VMs to inventory, place them in folders, resource pools, networks, etc and power them on as needed. If you are using Site Recovery Manager this process is all automated and you'll have the ability to test your failovers non-disruptively. Does that answer your question?
Answers in RED 1. Is there no way to specify WHEN the replication happens? from the VR FAQ - located here if you want more detail: "No. The replication schedule for a virtual mach... See more...
Answers in RED 1. Is there no way to specify WHEN the replication happens? from the VR FAQ - located here if you want more detail: "No. The replication schedule for a virtual machine is determined by the recovery point objective (RPO) set when configuring replication for that virtual machine. The possible value for RPO can be any number of minutes from 15 to 1,440 (24 hours). There is currently no way to schedule replication at specific times. vSphere Replication generates its own replication schedule internally by factoring all replicated virtual machines on each VMware vSphere host. A 48-hour replication schedule is computed using historic data change rates. The vSphere Replication scheduler calculates and updates this schedule after each delta sync and each time certain events occur, such as a change in virtual machine power state, replication reconfiguration, and so on. vSphere Replication attempts to spread out replication cycles to minimize the number of concurrent instances on a vSphere host. Because replication takes time to complete—especially with large amounts of data and slower network connections—each replica is considered “aged” by the time the current replication cycle completes. To avoid RPO violation, vSphere Replication attempts to complete a replication cycle in less than half of the configured RPO. Estimated transfer time is calculated by averaging the previous 15 delta replications and adding 20 percent to that average transfer time as a buffer." But what if I actually want the replication to happen around 6:00 pm instead of 11:15am? Do you have to actually initially setup that job at 6:00pm for it to replicate around that time each day? - There is currently no way to force a replication to occur at a specific time. Is this a feature you would have to purchase SRM to do? - This is not available as part of SRM either. SRM utilizes replication products (vSphere Replication and Array Based Replication) it has no impact or control over how they function. 2. Recovering VMs if the Replication Appliance is lost? This depends if you have lost the VRMS (vSphere Replication Management Server - the first VR appliance deployed to a vCenter) or a VRS (vSphere Replication Server - all subsequent VR appliances deployed to a vCenter). - If you lose the VRS, you should be able to recover your VMs. To get replication started again you will have to "reconfigure" replication to have it use a different appliance - If you lose a VRMS, you will not be able to recover VMs in a supported manner. In an unsupported manner you may be able to piece together the replicated data to recover your VMs. If you just want to setup replication again, you can likely use the replicated data as seeds. Regarding your initial scenario, keep in mind that if you are replicating from site A to site B with VR you would want your VR appliance to be located at site B (this is if you aren't using SRM - if you are using SRM you will have a VRMS server at each site so losing a VRMS/site won't cause any issues). We (availability Tech Marketing) are going to do some testing/research on backing-up/recovering VRMS. We'll post it on the vSphere Uptime blog - Uptime | VMware vSphere Blog - VMware Blogs) Hope this answers your questions?
Exactly. That's one of the main benefits of vSphere Replication. It's host based so the underlying storage doesn't matter.
Hi Sam, Welcome to the forums! With the percentage based admission control policy you are selecting how much of your cluster resources you want to reserve for use in a failover, so for your scen... See more...
Hi Sam, Welcome to the forums! With the percentage based admission control policy you are selecting how much of your cluster resources you want to reserve for use in a failover, so for your scenario where you have 3 hosts and you want to tolerate 1 host failure you would set them to 34% (round up). Keep in mind with this admission control policy that what counts against the % of cluster resources is: the VM overhead (CPU & Mem required by host/ESXi to run the VM) + and reservation for the VM. This is because admission control only guarantees that your VMs will restart, not that they will perform well. Hope this answers your question. If you're interested in reading more about HA I recommend: http://www.yellow-bricks.com/ http://frankdenneman.nl/ Amazon.com: VMware vSphere 5.1 Clustering Deepdive eBook: Duncan Epping, Frank Denneman: Kindle Store Cheers!
The main one you already highlighted, which is a general HA and vSphere best practice, make sure all LUNs are masked to all hosts in a cluster. Otherwise there aren't any others outside of sta... See more...
The main one you already highlighted, which is a general HA and vSphere best practice, make sure all LUNs are masked to all hosts in a cluster. Otherwise there aren't any others outside of standard HA best practice (same networks, port group names, etc). To insure you don't have any trouble you could start your VM on each host on the cluster to confirm there aren't any issues but that shouldn't be necessary.
From the vSphere Documentation Center If a host fails and its virtual machines need to be restarted, you can control the order in which this is done with the VM restart priority setting. You can... See more...
From the vSphere Documentation Center If a host fails and its virtual machines need to be restarted, you can control the order in which this is done with the VM restart priority setting. You can also configure how vSphere HA responds if hosts and how vSphere HA responds if hosts lose management network connectivity with other hosts by using host isolation response setting. These settings apply to all virtual machines in the cluster in the case of a host failure or isolation. You can also configure exceptions for specific virtual machines. See Customize vSphere HA Behavior for an Individual Virtual Machine. VM Restart Priority VM restart priority determines the relative order in which virtual machines are placed on new hosts after a host failure. Such virtual machines are restarted, with the highest priority virtual machines attempted first and continuing to those with lower priority until all virtual machines are restarted or no more cluster resources are available. Note that if vSphere HA fails to power on a high-priority virtual machine, it does proceed to try any lower-priority virtual machines. Because of this, the VM restart priority cannot be used to enforce a restart priority for a multiple virtual machine application. Also, if the number of hosts failures exceeds what admission control permits, the virtual machines with lower priority might not be restarted until more resources become available. Virtual machines are restarted on the failover hosts, if specified. The values for this setting are: Disabled, Low, Medium (the default), and High. If you select Disabled, vSphere HA is disabled for the virtual machine, which means that it is not restarted on other ESXi hosts if its host fails. The Disabled setting is ignored by the vSphere HA VM/Application monitoring feature since this feature protects virtual machines against operating system-level failures and not virtual machine failures. When an operating system-level failure occurs, the operating system is rebooted by vSphere HA and the virtual machine is left running on the same host. You can change this setting for individual virtual machines. ------ The thing with VM restart priority is that it currently the order that startup of VMs is attempted after an HA event. It isn't a guarantee that VMs will start in a particular order. It may work for your environment though. I'd recommend testing it out if you can. Here is a post from www.yellow-bricks.com talking about Restart Priorities and some of the issues with them in more detail: I set restart priorities but still my VMs seem to be powered on in a different order And here is a rough idea of what we're looking at for futures: http://www.yellow-bricks.com/2013/09/13/ha-futures-restart-order/ Hope this helps.
I'm going to assume that your remote site is it's own cluster? If not, there are a number of additional complications that would take a long time to get into. Also, keep in mind that the HA pr... See more...
I'm going to assume that your remote site is it's own cluster? If not, there are a number of additional complications that would take a long time to get into. Also, keep in mind that the HA process is independent of vCenter. It doesn't require vCenter to operate, just for configuration setup/changes. Answers in RED Scenario 1: VMs in protected mode are shutdown on ESXi02 Will HA on the ESXi01 think this is an error and try to recover the VM's on ESXi01? - No, if you shutdown a VM HA will not take action Scenario 2: ESXi02 has shutdown all it's VM's and now powered down Will ESXi01 think ESXi02 is isolated and now try to recover those VM's on ESXi01?- No, No Does this answer your questions?
Welcome to the forums. I'll try and answer your questions. Keep in mind that you're talking about 3 different products/features (vSphere HA, vSphere Replication and vMotion) that have different f... See more...
Welcome to the forums. I'll try and answer your questions. Keep in mind that you're talking about 3 different products/features (vSphere HA, vSphere Replication and vMotion) that have different functionality. Host A fails what do I use? if HA powers on VMs in Host B then I will end up with duplicated powered on VMs? wouldn't I use the replicated VMs? - You won't end up with duplicated powered on VMs because with vSphere Replication the replica VM isn't running. HA will re-start the VM that was running on Host A on Host B, no need to restore from the replica copy. Again wouldn't I have the same issue when using vMotion? - No, vMotion will move a running VM from one host to another (eg. from host A to host B). There isn't any downtime for a vMotion. HA is used to protect against host or operating system issues. It will restart a VM if the host fails or if the operating system crashes (if it is configured for this). vSphere Replication is used for replicating VM(s) from one datastore to another. The datastores can be at the same site, different sites or even different vCenters. vSphere Replication supports RPOs of 15 mins - 24 hrs as well as Multiple Point in Time replication. vMotion is used to migrate a running VM from one host to another host with no downtime. Storage vMotion allows for the movement of a VMs storage (from one datastore to another) without downtime. Hope this helps. If you have more questions about any of these products/features I'd suggest looking into them on the VMware site, blogs and these forums. If you still can't find an answer ask it here.
Are you running into a throughput issue when using 1 nic for FT? Currently FT only supports using a single nic (1G or 10G)