You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the fact that you can have multiple objects in vCenter with the same name on different levels of the vCenter inventory is not respected. Commands will fail if more then a single object with the used name exists.
E.g., let's take a look at the New-ZertoVpg commandlet.
When multiple clusters with multiple distributed switches exist, portgroups can have the same name across all those switches.
Currently when providing the -recoveryNetwork or -testNetwork parameter to the commandlet it will then use this code to find the matching network by name:
If more then one network exists the Zerto API will attach the VDS name to the network name, e.g.: if a network my_test_network exists in a VDS named vds_a and vds_b then the Zerto API will return my_test_network (vds_a) and my_test_network (vds_b) for the VirtualizationNetworkName property.
Thus in such cases the compare operation using -like will return no result and the commandlet will fail with an error like failoverNetworkIdentifier is not associated with a valid identifier. Please check the submitted values and try again.
While this example of the issue was specific for networks it exists for other objects as well, e.g. folder names.
The wrapper should handle such cases. E.g. if no exact match for my_test_network exists but multiple results for my_test_network* exist then a propper exception should be raised at very least.
In some cases it would probably be possible to handle this in an automated manner. E.g. the target cluster is known and the network is unique within the cluster, then it's clear what network the user desires to use.
The text was updated successfully, but these errors were encountered:
@M451 - Thanks for raising this issue. You bring up a very good point that I had not taken into account but does need to be addressed.
From a programatic perspective, when querying networks (or any other item that could have a duplicate), the only data returned is the name and identifier. Even if we had the target cluster or host, we would not currently be able to filter based on this information to automatically select the correct identifier. With this in mind, I will raise a feature request with the Zerto team to incorporate a filter function.
The one idea I currently have would be to change the compare operation from a -like to a -match. I am going to need to dig into this further and do some testing to see what the impacts of this would be and how we would handle the logic in this case.
For the next few weeks I am on vacation and then will be attending VMworld. I should have time to dig in around the first week in September.
btw: I just noticed that the documentation PDF is wrong. It sais that the datacenter name is attached if multiple pgs with the same name exist. However: that doesn't seem to be true (or at least that's not the whole story) since in my tests the DVS name was attached to the names.
Currently the fact that you can have multiple objects in vCenter with the same name on different levels of the vCenter inventory is not respected. Commands will fail if more then a single object with the used name exists.
E.g., let's take a look at the
New-ZertoVpg
commandlet.When multiple clusters with multiple distributed switches exist, portgroups can have the same name across all those switches.
Currently when providing the
-recoveryNetwork
or-testNetwork
parameter to the commandlet it will then use this code to find the matching network by name:If more then one network exists the Zerto API will attach the VDS name to the network name, e.g.: if a network
my_test_network
exists in a VDS namedvds_a
andvds_b
then the Zerto API will returnmy_test_network (vds_a)
andmy_test_network (vds_b)
for the VirtualizationNetworkName property.Thus in such cases the compare operation using
-like
will return no result and the commandlet will fail with an error likefailoverNetworkIdentifier is not associated with a valid identifier. Please check the submitted values and try again
.While this example of the issue was specific for networks it exists for other objects as well, e.g. folder names.
The wrapper should handle such cases. E.g. if no exact match for
my_test_network
exists but multiple results formy_test_network*
exist then a propper exception should be raised at very least.In some cases it would probably be possible to handle this in an automated manner. E.g. the target cluster is known and the network is unique within the cluster, then it's clear what network the user desires to use.
The text was updated successfully, but these errors were encountered: