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
Copy file name to clipboardExpand all lines: python/avi/sdk/samples/clone_vs.md
+38-6
Original file line number
Diff line number
Diff line change
@@ -72,18 +72,20 @@ Specify the VIP as a subnet/mask. This must match an auto-allocation subnet in I
72
72
73
73
If the source VIP was auto-allocated, the target can simply inherit the auto-allocation network:
74
74
75
-
> -v *
75
+
> -v auto (or -v *)
76
+
77
+
(Note: On Linux/Unix/Mac systems, use the `auto` option as `*` would need to be escaped to prevent it being treated as a filename glob)
76
78
77
79
### Specifying public/elastic/floating IP for clouds that support this (e.g. public clouds, OpenStack)
78
80
79
-
Separate the public/floating IP using a `;`. A static public/floating IP can be specified explicitly, or o auto-allocate a public IP, use the `auto` keyword:
81
+
Separate the public/floating IP using a `;`. A static public/floating IP can be specified explicitly, or to auto-allocate a public IP, use the `auto` keyword:
80
82
81
83
> -v 10.10.10.0/24;203.0.113.100
82
84
> -v 10.10.10.0/24;auto
83
85
84
86
### Avi Internal IPAM
85
87
86
-
When using Avi Internal IPAM for auto-allocation, it may be necessary in some clouds (e.g. NSX-T Cloud) to supply the `-int` parameter to ensure the VsVip is populated with all the correct fields. Other clouds (e.g. vCenter Cloud) are more forgiving and usually work without specifying this parameter.
88
+
When using Avi Internal IPAM for auto-allocation, it may be necessary in some clouds (e.g. NSX-T Cloud) to supply the `-int` parameter to ensure the VsVip is populated with all the correct fields. Other clouds (e.g. vCenter Cloud) are more forgiving and generally work without specifying this parameter if there is only a single IPAM subnet specified.
87
89
88
90
## Special flags
89
91
@@ -212,17 +214,17 @@ If cloning a Virtual Service between Controllers or to a different tenant, the d
212
214
213
215
A WAF Policy and its referenced PSM groups can be forced cloned using the -fc flag. This supports the scenarios where the cloned VS should have its own WAF Policy rather than sharing the same WAF policy (including the case where learning is enabled).
214
216
215
-
In this case, if learning is enabled in the source WAF Policy, it will remain enabled in the cloned WAF Policy resulting in indepdent learning for the cloned VS.
217
+
In this case, if learning is enabled in the source WAF Policy, it will remain enabled in the cloned WAF Policy resulting in independent learning for the cloned VS.
216
218
217
219
The below example clones a VS and forces cloning of the WAF Policy and any PSM groups also.
218
220
219
-
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model vs example cloned-example -v *
221
+
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model vs example cloned-example -v auto
220
222
221
223
### Disabling learning in the cloned WAF Policy
222
224
223
225
It may desirable to disable learning for the cloned WAF Policy and its referenced PSM groups, for example if the source Virtual Service was used for learning and the cloned Virtual Service will be an instance of the same application, but independent learning is not desired. This can be achieved with the option `-flags disablelearning`:
224
226
225
-
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model -flags disablelearning vs example cloned-example -v *
227
+
> clone_vs.py -c controller1.acme.com -fc vs-wafpolicy,positive-security-model -flags disablelearning vs example cloned-example -v auto
226
228
227
229
This flag can also be used when cloning a WAF Policy individually:
228
230
@@ -300,3 +302,33 @@ Changelog:
300
302
2.0.2:
301
303
302
304
* Added support for flexibly handling specification of pool placement networks for cloned pools
305
+
306
+
2.0.3:
307
+
308
+
* Added some additional reference handling for less-common DataScript and WAF Profile configurations
309
+
310
+
2.0.4:
311
+
312
+
* Fixed VRF handling for cloning to/from NSX-T Cloud in certain scenarios
313
+
314
+
2.0.5:
315
+
316
+
* Fixed VRF handling with manual VsVip
317
+
318
+
2.0.6:
319
+
320
+
* Changed handling of Pool and PoolGroup references in VsDataScriptSet
321
+
* Will now try to preserve the names of Pools and PoolGroups when cloning a VsDataScriptSet if possible (e.g. when cloning to a different tenant/Controller)
322
+
* If name preservation is not possible, unique names will now be generated from the old Pool/PoolGroup name (previous behaviour was to generate names based on VsDataScript name)
323
+
* Will generate a warning that DataScript code changes may be needed, for example because a Pool or PoolGroup name could not be preserved
324
+
* Changed handling of PoolGroup cloning
325
+
* Will now try to preserve the names of Pools when cloning a PoolGroup if possible (e.g. when cloning to a different tenant/Controller)
326
+
* If name preservation is not possible, unique names will now be generated from the old Pool name (previous behaviour was to generate names based on PoolGroup name)
327
+
328
+
2.0.7:
329
+
330
+
* Add support for cloning HealthMonitors with SSL attributes or authentication attributes (authentication attributes must be manually re-entered)
331
+
* Add support for cloning AuthProfiles for OAuth2
332
+
* Add support for cloning VS with OAuth2 SSO configuration
333
+
* Add support for cloning VS with service-level network/application profile overrides
334
+
* Add support for cloning DNS VS with Topology Policies
0 commit comments