Forum Discussion

Braden_Walters_'s avatar
Braden_Walters_
Icon for Nimbostratus rankNimbostratus
Apr 29, 2014

Cannot delete virtual server because of sflow

Hey all,

I have a lab setup with two LTMs in HA, and was trying to clear out some configs, when the standby suddenly refused to sync properly. When I examined the standby system's logs, I saw the following log message:

Apr 29 12:15:18 bigip02 err mcpd[6125]: 01070265:3: The Virtual Server (/Common/VIP-v302-HTTP) cannot be deleted because it is in use by a sflow http data source (2).

This was somewhat of a surprise, as I have never explicitly set up sflow on either device. I have so far tracked it down to possibly being there because of an iRule I was playing with that required an http profile, which is apparently (if I am reading it right) the reason for the data-source being there:

root@(bigip02)(cfg-sync Not All Devices Synced)(Standby)(/Common)(tmos.sys.sflow) show data-source http all-properties 

------------------------------------------------------------------------------------------------
Sys::sFlow Data Source: HTTP
Virtual Server Name  HTTP Profile Name  Poll Interval  Sampling Rate  Active  Index  Subagent ID
------------------------------------------------------------------------------------------------
VIP-v302-HTTP                     http             10           1024      no      2            0

In any case, I removed the iRule from the virt just in case, and even removed the http profile from it, but still no joy. The data source remains there, and I can't figure out how to remove it. There seems to be no way to do so in the config utility, and it doesn't seem to have a specific identifier I can use to delete it in tmsh:

root@(bigip02)(cfg-sync Not All Devices Synced)(Standby)(/Common)(tmos.sys.sflow) list
sys sflow global-settings http { }
sys sflow global-settings interface { }
sys sflow global-settings system { }
sys sflow global-settings vlan { }

Does anyone have any suggestions how I can remove this data source so that I can sync my systems?

  • can you try this?

    on active
     tmsh modify cm device-group (device group name) devices modify { (active device name) { set-sync-leader } }
     tmsh run /cm config-sync to-group (device group name)
    
    on standby
     touch /service/mcpd/forceload
     reboot
    

    ID441512 - config sync fails w/ Database error (13), Can't save/checkpoint DB object, class:sflow_http_virtual_data_source status:13 - EdbCfgObj.cpp, line 127

  • can you try this?

    on active
     tmsh modify cm device-group (device group name) devices modify { (active device name) { set-sync-leader } }
     tmsh run /cm config-sync to-group (device group name)
    
    on standby
     touch /service/mcpd/forceload
     reboot
    

    ID441512 - config sync fails w/ Database error (13), Can't save/checkpoint DB object, class:sflow_http_virtual_data_source status:13 - EdbCfgObj.cpp, line 127

    • Braden_Walters_'s avatar
      Braden_Walters_
      Icon for Nimbostratus rankNimbostratus
      That was interesting ... This basically worked, in that the standby did pick up the change in config and removed the VIP in question, but I got into a cycle of sync issues that took a couple of reboots on each side to resolve. Initially, when the standby came up, I was getting "Disconnected" on both VMs, even though they had a clear HA Network path. So I rebooted the Active, and it came back connected, but "Not all devices in sync". It appeared as though it labelled the config on the Standby as newer than on the Active, and it took some work to get them to finally sync.
    • Terry_Phillips1's avatar
      Terry_Phillips1
      Icon for Nimbostratus rankNimbostratus
      Thank you nitass - your solution got me past a rookie mistake and moving forward again....
  • can you try this?

    on active
     tmsh modify cm device-group (device group name) devices modify { (active device name) { set-sync-leader } }
     tmsh run /cm config-sync to-group (device group name)
    
    on standby
     touch /service/mcpd/forceload
     reboot
    

    ID441512 - config sync fails w/ Database error (13), Can't save/checkpoint DB object, class:sflow_http_virtual_data_source status:13 - EdbCfgObj.cpp, line 127

    • Braden_Walters_'s avatar
      Braden_Walters_
      Icon for Nimbostratus rankNimbostratus
      That was interesting ... This basically worked, in that the standby did pick up the change in config and removed the VIP in question, but I got into a cycle of sync issues that took a couple of reboots on each side to resolve. Initially, when the standby came up, I was getting "Disconnected" on both VMs, even though they had a clear HA Network path. So I rebooted the Active, and it came back connected, but "Not all devices in sync". It appeared as though it labelled the config on the Standby as newer than on the Active, and it took some work to get them to finally sync.
    • Terry_Phillips1's avatar
      Terry_Phillips1
      Icon for Nimbostratus rankNimbostratus
      Thank you nitass - your solution got me past a rookie mistake and moving forward again....
  • Hi,

    I recently faced the same issue. But I was under the impression it resulted from a modified default http profile.

    To resolve the problem I manually deleted the modified http profile from /config/bigip.conf and reloaded the configuration from config files after stopping the mcpd, deleting the binary config files and restarting the mcpd on the affected unit.
    bigstart stop mcpd
    rm /var/db/mcpdb.*
    bigstart start mcpd
    tmsh load sys config
    

    Now config save and config sync worked properly. Instead of modifying the default http profile, a new profile (defaults from http) was created with the required standard settings to be used now as master template for new http profiles. Please be careful when applying the steps above. If in doubt, open a case with F5 support.

    Thanks,

    Stephan

    PS: Modifying the default profiles always seemed to be a bad idea. But in case of analytics profile it´s actually required i.e. to track client subnets.
  • According to v11.5.1HF5 release notes this issue is fixed now:

     

    474166-2

     

    An error of the form "Can't save/checkpoint DB object, class:sflow_http_virtual_data_source status:13" will no longer appear.

     

  • Jason_Reed_4703's avatar
    Jason_Reed_4703
    Historic F5 Account

    In another instance of this issue (on 11.5.1 HF5), they were able to disable the VIP on the standby and then sync their configuration.

     

    • Arun_LK_202176's avatar
      Arun_LK_202176
      Icon for Nimbostratus rankNimbostratus
      In this same scenario, i removed the parent HTTP profile and added a custom profile and things worked. I was able to delete the vip.
  • In another instance of this issue (on 11.5.1 HF5), they were able to disable the VIP on the standby and then sync their configuration.

     

    • Arun_LK_202176's avatar
      Arun_LK_202176
      Icon for Nimbostratus rankNimbostratus
      In this same scenario, i removed the parent HTTP profile and added a custom profile and things worked. I was able to delete the vip.
  • "... and even removed the http profile from it, but still no joy" you may also try this: 1. @HTTP Profile: remove your assigned http profile (ex. http). choose NONE to be safe. then click update. 2. @HTTP Profile: change from NONE to original http profile (ex. http). then click update. 3. then delete the VS. 4. then sync.