[DOCS-7366] We should recommend against using VMotion Created: 08/Mar/16 Updated: 30/Oct/23 Resolved: 08/Mar/16 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Steven Hand | Assignee: | Allison Reinheimer Moore |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
ESXi 5 plus |
||
| Issue Links: |
|
||||
| Participants: | |||||
| Days since reply: | 7 years, 49 weeks, 1 day ago | ||||
| Description |
|
The VMotion feature of vSphere (and of ESXi, which really does the work) is setup to provide service availability and storage availability by virtual of a distributed file system shared amongst all cluster members. Our replica set feature does the same thing. Using VMotion with Replica Set is duplicate effort and causes problems. If the move of the RS member takes too long, then elections occur. I recently had a case where this was clearly the problem. We should recommend against using VMotion with Replica Sets. |
| Comments |
| Comment by Allison Reinheimer Moore [ 08/Mar/16 ] | |||||
|
We've added the following to the production notes – the changes are currently in a code review with the revision of the production notes, but will hopefully make it into the manual shortly.
Let me know if you'd like us to add more detail! |