Can I change the type of a vService later?
Short answer
No. The type of a vService (HTTP, L7 TCP, Network) is selected at creation time, and the Type field is locked on the edit screen. If a different type is needed, a new vService of the new type is created; since there is no feature that copies vServices, the settings are re-entered in the new vService. If the new vService will use the same IP:port, the old vService is first deleted or the port it listens on is changed so that there is no port collision; disabling it is not enough, because the IP:port of a Disabled vService stays reserved.
How Does It Work?
The type determines which fields the form contains and at which level the traffic is processed: HTTP reads the request as HTTP, L7 TCP accepts the connection on TR7 but does not interpret the content, and Network forwards the packets without terminating the connection (How many types of vService does TR7 have, and how do they differ?). Since the settings of each type are different, a type change is not a field update but means a different vService. Also while a new vService is being created, when the type is changed, the form resets the frontend rows, the modules and the actions.
Switching to a Different Type
| # | Step |
|---|---|
| 1 | The settings of the old vService are noted (frontend, Backend Services, algorithm, persistence, profiles, actions). Load Balancer Management is used to read them on a single screen. |
| 2 | If the same IP:port will be used, in a maintenance window the old vService is deleted, or the frontend port of the old vService is changed to an unused port and saved. Only disabling the old vService is not enough. |
| 3 | A vService of the new type is created with Load Balancer → Load Balancer vService List → Add, and the settings that have a counterpart in the new type are re-entered; since Backend Services, profiles and conditions are shared objects, they are not recreated, only selected. |
| 4 | It is saved with Save, and the new vService is tested. In a cluster setup, the changes are also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, they are sent manually with Synchronize. |
If a different IP can be used, the new vService is first set up side by side and tested, then DNS is pointed to the new address and the old vService is deleted; this path causes no interruption. If the new IP is not defined on TR7, it is first added with Network → Interfaces → Actions → Add IP (Add IP Address).
Common Misconceptions
- "I disable the old vService and open a new one with the same IP:port." The IP:port of a Disabled vService stays reserved; the same address cannot be used unless the old vService is deleted or its port is changed, and the form shows the "Port collision" error.
- "I copy the vService and change its type." There is no vService copy feature; Export in the list only exports the table as Excel, CSV or PDF.
- "I must recreate the Backend Services as well." Backend Services, profiles and conditions are objects independent of the vService; they are only selected in the new vService.
- "Some settings are carried over to the new type as they are." Only the settings that have a counterpart in the new type can be entered; for example, when moving from HTTP to L7 TCP, there is no WAF, Cache, Compression or X-Forwarded-For (What are the feature differences between HTTP, L7 TCP and Network vServices?).
How it is done in the documentation
