[SKIP CI] Update Site Recovery Manager's behavior with vDVS #1788
Conversation
Interop.md
Outdated
|
|
||
| User created vmgroup is not supported with SRM. | ||
|
|
||
| - After disaster recovery finishes, 'admin cli volume ls' command lists vmgroup for volumes of user created vmgroup as 'N/A' at secondary site and all VMs that were part of user created vmgroup will become part of default vmgroup and will start seeing volumes of default vmgroup. [#1786](https://github.com/vmware/docker-volume-vsphere/issues/1786) |
There was a problem hiding this comment.
need to add: volumes become accessible
Interop.md
Outdated
|
|
||
| User created vmgroup is not supported with SRM. | ||
|
|
||
| - After disaster recovery finishes, 'admin cli volume ls' command lists vmgroup for volumes of user created vmgroup as 'N/A' at secondary site and all VMs that were part of user created vmgroup will become part of default vmgroup and will start seeing volumes of default vmgroup. [#1786](https://github.com/vmware/docker-volume-vsphere/issues/1786) |
There was a problem hiding this comment.
After disaster recovery finishes, esxcli volume ls shows N/A (volume<->vmgroup relation) for the volumes part of user created vmgroup at the secondary site and all VMs that were part of user crated vmgroup will fall into _DEFAULT vmgroup and gain access to all volumes in short it looses granted privileges and set resource consumption and resulting into full access or access right set for _DEFAULT vmgroup.
How about this?
Interop.md
Outdated
|
|
||
| User created vmgroup is not supported with SRM. | ||
|
|
||
| - After disaster recovery finishes, 'admin cli volume ls' command lists vmgroup for volumes of user created vmgroup as 'N/A' at secondary site and all VMs that were part of user created vmgroup will become part of default vmgroup and will have access to volumes of default vmgroup. [#1786](https://github.com/vmware/docker-volume-vsphere/issues/1786) |
There was a problem hiding this comment.
After disaster recovery finishes, esxcli volume ls shows N/A (volume<->vmgroup relation) for the volumes part of user created vmgroup at the secondary site and all VMs that were part of user crated vmgroup will fall into _DEFAULT vmgroup and gain access to all volumes in short it looses granted privileges and set resource consumption and resulting into full access or access right set for _DEFAULT vmgroup.
How about this?
There was a problem hiding this comment.
I think the root cause is not this. The volume was created from a vm belongs to user created vmgroup. After SRM, the vmgroup configuration is not replicated to the destination, and therefore, it cannot find the which vmgroup those volumes belong to. It has nothing related with _DEFAULT vmgroup.
Interop.md
Outdated
|
|
||
| User created vmgroup is not supported with SRM. | ||
|
|
||
| - After disaster recovery finishes, ```esxcli volume ls``` shows 'N/A' (volume<->vmgroup relation) for the user created vmgroup's volumes at the secondary site and all VMs that were part of user created vmgroup will fall into `_DEFAULT` vmgroup and will have access to volumes of `_DEFAULT` vmgroup - in short it looses the volumes that were part of user created vmgroup and gains access to volumes of `_DEFAULT` vmgroup. [#1786](https://github.com/vmware/docker-volume-vsphere/issues/1786) |
There was a problem hiding this comment.
I think the root cause is not this. The volume was created from a vm belongs to user created vmgroup. After SRM, the vmgroup configuration is not replicated to the destination, and therefore, it cannot find the which vmgroup those volumes belong to. It has nothing related with _DEFAULT vmgroup.
There was a problem hiding this comment.
@lipingxue Added this information. Please take a look.
Addressed review comments from Liping
ashahi1
force-pushed
the
updateKnownIssues.ashahi1
branch
from
66d40d8
to
62452f6
Compare
User created vmgroup does not work as expected with Site Recovery Manager - Issue #1786
Updating this behavior to Interop.md