Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology

Changing Virtual Server type from Internal to Standard

We have a couple Virtual Servers for some reason are type "internal". When we first went through PS they instructed us to create the servers as standard with the the IP included and then change the type from Standard to Internal through the GUI. This works but the problem is every time we upgrade or apply HFs if we forget to change these to Standard before the upgrade/reboot the system comes up without a configuration and we have to call support to restore the config and then go back through each virtual server we have that is Internal and change it to Standard then upgrade successfully and after change them back to Internal.

So I have two questions:

1. Is this Internal vs Standard still necessary as a permanent config? (I ask because the original PS told us this was a bug and every time I ask support they say the same).

2. Is there a way to automate or script the change via TMSH to change Virtual Servers "types"? I am in no way an F5 expert but from just listing and modifying individual Virtual Servers it requires editing individually so not sure it's possible without deleting and re-creating the Virtual Server via TMSH.
Rate this Question
Comments on this Question
Comment made 17-Dec-2017 by boneyard 5579

interesting question, can't say much about 1, if support says it is the case i would believe them. you can always try to see if it fails. which version is this about btw?

as for 2 that is annoying, can add internal fine with TMSH, but removing seems harder. hopefully someone else can give you the solution.

Comment made 17-Dec-2017 by S Blakely

There is currently no way (using tmsh or iControl) to correctly modify the type of a virtual server (for certain combinations of virtual type). This includes attempting to change an internal virtual to a standard virtual.

There is a internal change request to have this addressed in an unspecified future release.

I'd be interested to know the specific error that prevents the config from loading following an upgrade.

As far as I am aware, you should only use an internal type for ICAP profiles.

Comment made 18-Dec-2017 by CP16 11

Thanks for the info. We are now on 12.1.2 hf2.

I worked with support again after the upgrade and the engineer took the information because he never experienced this problem either.

If we forget to change the type to standard before an upgrade the system will boot up and I can tell the problem exists because my AD credentials won't work and am forced to use my local login. When you attempt to load the sys config the following error is received

"Virtual Address /prod/ in partition prod cannot be referenced by Virtual Server /uat/v-sp-uat-pwp-owa-all in partition uat Unexpected Error: Loading configuration process failed."

These virtual servers are hopefully going away soon but I appreciate the feedback.

Comment made 18-Dec-2017 by S Blakely

Have you tested to see if those virtuals work when set to Standard?
Do they work as expected?
I can see no reason for them to be configured that way.

The config loading problem is that a virtual of type internal has a sort of template applied to it - for an internal virtual, this sets the destination to, overwriting the configured destination. It also sets the listening vlan to none so that no external traffic hits the vip - the traffic should be directed to the virtual via an irule (using the virtual command) or an ICAP profile.

The partition that your virtual is defined in does not have a virtual address, so a virtual address in another partition is selected, which is an invalid choice causing the config load issue.

K14675: Error Message: 01070726:3: virtual server <Partition/Virtual_Name> in partition cannot reference virtual address <Partition/Virtual_Addr> in partition

As detailed in:

K15819: Overview of the internal virtual server

the internal virtual server is only intended to be used to configure ICAP Content adaption, and has no other purpose. I really do not understand why this has been configured in this way.

As you seem to be getting rid of these virtuals, I'd recommend that you do so as soon as possible. This should resolve your future upgrade issues.

Comment made 18-Dec-2017 by CP16 11

Thanks Blakely.

I don't recall exactly why they set this up this way but if you change it to standard it does break so as you suggested I will be pushing to get rid of these ASAP


Answers to this Question


Hello, To change a VS to FastL4:

mplaksin@(f-f5)(cfg-sync In Sync)(/S2-green-P::Active)(/xx)(tmos)# modify ltm virtual nat8 profiles replace-all-with { fastL4 }

To change VS to Standard: mplaksin@(f-f5)(cfg-sync In Sync)(/S2-green-P::Active)(/xx)(tmos)# modify ltm virtual nat8 profiles replace-all-with { tcp { context all } }

Comments on this Answer
Comment made 1 week ago by MikeEQ8 105

The cmd doesn't appear to work if the server type is a Forwarding-IP, can't change it back to standard. Have read else where on dev central this has been requested in future code releases.