You can move certain BIG-IP objects from one folder to another, and optionally, you can rename the objects in the process. In general, the objects that you can move and rename are:
This table lists and describes a few restrictions to be aware of when moving BIG-IP Local Traffic Manager (LTM) objects from one folder to another.
|Global traffic management||When you move a local traffic virtual server that is associated with a GTM configuration, GTM must re-discover the virtual server. This could affect the status of the GTM objects associated with the virtual server. To avoid any disruption in GTM service or loss of statistics, contact your GTM administrator before moving or renaming a virtual server.|
|iRules||You cannot move an object if the object is referenced by an iRule and the iRule is in use by a virtual server. Such an attempt produces an mcpd runtime configuration error. The behavior mimics the deletion of referenced objects; that is, you can delete a pool when the pool is used by an iRule, as long as a virtual server is not referencing the iRule.|
|Object referencing||If an object is associated with another object, you cannot move the object to a different high-level folder corresponding to a partition. The BIG-IP system disallows this type of move in order to prevent an invalid object reference. For example, if a virtual server in /Common references a profile in /Common, you cannot move the profile to folder /Partition. Doing so would result in an invalid reference. As a best practice, objects such as pools or profiles that are used by multiple objects such as virtual servers should reside in folder /Common.|
|Default profiles||You cannot move a default profile from folder /Common to another folder. All default profiles on the system must remain in /Common.|
|Health monitors||You cannot move multiple monitors that are associated with more than one monitor rule. The BIG-IP system terminates any attempt to perform this type of move operation.|
|iApps||When you move an iApp application service, you must move the entire iApp folder, which includes the service object and all dependant objects. If an iApp service contains an object that does not currently support the mv command, the move operation terminates with a message indicating the object that the BIG-IP system cannot move.|
You can enable a feature that allows you to move certain BIG-IP configuration objects from one folder to another or to rename a BIG-IP object. By using this feature, you avoid the need to delete an object in a folder and recreate the object in another folder. Note that after enabling this feature, you must use the Traffic Management Shell (tmsh) command line interface to move or rename BIG-IP objects.
After managing configuration objects or folders you might want to disable the ability to move certain BIG-IP configuration objects from one folder to another or to rename a BIG-IP object using the command line.
You can use this feature in several ways.
You can move a single local traffic object to another folder. In this case, you use the tmsh mv command with the to-folder keyword.
You can move multiple objects to the new folder, as long as all objects are of the same type. For example, in a single move operation, you can move three pools to a single folder. In this case, you are not required to specify the to-folder keyword.
You can move an object to another folder with a single command, using a relative path name and the to-folder keyword.
You can rename an object without moving the object to another folder.
You can rename an object and move the object to another folder, in a single operation.
You can move a local traffic object out of an iApp folder into other folders or sub-folders of an application without breaking the connection to the parent iApp service, allowing for custom organization. For example, you can move pool my_pool in the iApp folder /Common/myapp.app to a non-iApp folder. The following are two examples:
mv ltm pool /Common/myapp.app/my_pool /Common/allpools/my_pool
mv ltm pool /Common/myapp.app/my_pool /Common/myapp.app/pools/my_pool
If a local traffic object was not created as part of an iApp service, you can still move the object into an iApp folder and automatically associate it with that iApp service. For example, you can move the object my_pool into the iApp folder /myapp.app, renaming the object at the same time:
mv ltm pool /Common/pools/my_pool /Common/myapp.app/my_app_pool
You can move local traffic objects directly from one iApp folder to another. You can do this in either of two ways. For example:
mv ltm pool /Common/myapp.app/app_pool_1 to-folder /Common/myapp2.app
mv ltm pool /Common/myapp.app/app_pool_1 /Common/myapp2.app/app_pool_1
Additionally, you can move multiple objects of the same type from one iApp service to another iApp service, simply by using a multi-source mv command:cd /Common/myapp.app mv ltm pool app_pool_1 app_pool_2 app_pool_3 to-folder /Common/myapp2.app
You can move an entire folder to another folder. When you move a folder to another folder, the BIG-IP system also moves all objects in the moved folder. The system disallows this type of move operation if the move breaks normal object rules, such as if the move would cause an object to reference an object in another partition.
If the moved folder inherits any attributes from its parent folder, the value of those attributes could change after the folder is moved. For example, before a move operation, a folder might inherit a device group value of my_sync_only_device_group from its parent folder. If you move the folder to a folder that inherits a device group value of my_sync_failover_device_group, the moved folder inherits that new value.