Deleting VSX VS object from Smart Console / management server

[S_K_S]

We are trying to re-configure one of our VSX clusters (R80.40 take 91, the management is the same version) with different virtual firewalls and in order to do so, the existing ones should be deleted first (the new firewalls will use the IP addresses currently assigned to the existing firewalls). When I try to delete a VS object from the Smart Console however, it tells me that it's referenced in another object which is actually a representation on the VSX itself (can be seen when going to VS object -> Cluster Members) - and that can't be deleted or at least I cannot find where to delete it from. The objects in question are in the attachment. Any idea how to get rid of that thing?

[genisis__]

Is the VS and VSX cluster in the same DMS, and is the DMS the main DMS that manages the VSX Cluster?   Also have you checked installed targets on security polices to see if this is defined?

[S_K_S]

Both are on the same management server. We have a secondary Smart Center in HA with this one but I don't believe that's an issue.

[genisis__]

Did you check your policy install target field, to ensure the VS your trying to delete is not specified as a target, also any VPN communities.

[S_K_S]

Yes, everything is cleared - policy is detached, no encryption domain, no VPN communities, etc. The only thing which shows as an obstruction are these two objects from the screenshot above which have "Yes" in the "Is removable?" field and that non-removable thing from the rule_base table which cannot be searched for.

[genisis__]

Strange - does it actually stop you from deleting or its just telling you?  (Do a backup first, just in case), other option is log a TAC case.

[S_K_S]

It wouldn't let me delete it, yes. However, it just occurred to me that the reason might be that object from the rule_base table and not the two other (the VS representation on the two VSX cluster members). Even though the policy package is detached, the VS still has some blades enabled, AV and Anti-Bot among them, which might have some "hidden" base rules - I remember that there was some such case with IPS. I'll try disabling all blades except the firewall one and attempt deleting the object again.

[the_rock]

Hi there,

Im not and have never been VSX expert (so wont pretend to be one here :)), but just from logical point of view, what if you go into guidbedit and search for that object and try delete it that way?

[S_K_S]

Tried it after the first few failed attempts, didn't work 🙂 It says the object is referenced by another object.

[genisis__]

Becareful with GUIDBedit, you can cause serious damage, always ensure you have a recovery position if you make changes to this.

At this point it may be quicker to raise a TAC case, if all visible references have been removed, then may need to edit the postgres database and check in there.

I had an issue like this in the past (not quite the same) and TAC had to delete some entries in the Postgres (Only after a backup and snapshot where taken).

[JozkoMrkvicka]

TAC case is indeed needed here.

They have also some nice scripts to delete objects which are not able to be deleted from GUI (not used objects).

[the_rock]

Ok, fair enough...I think responses from other people are definitely valid and logical. I would agree that with guidbedit in general, you should document everything you do and have full backup, just in case. Just curious though, can you send us a screenshot of what it shows when it complains its referenced by other object when you attempt to delete it from guidbedit?

[genisis__]

There are documented changes that could can do using GUIDBedit, example changing VPN MTU size.  In terms of errors, thankfully I've never had a major issue, so can't really comment too much on error messages.

If TAC resolve this, please do let us know what was done, if its anything other then deleting references from postgres.

Also may be good to run cpm doctor as well to catch any other issues to be reported to TAC.

[the_rock]

I agree with you, all good points! Personally, even back in R55, was never a big fan of changing anything in guidbedit. I always found it odd that database with CP is co complicated...never seen anything like that with other vendors, but again, that could be since CP management is the best out there.

[S_K_S]

Normally I wouldn't touch dbedit unless all other options are exhausted but in my experience if something can't be edited properly through the Smart Console/Dashboard, it also can't be changed with the dbedit tools (unless of course the thing in question is not visible on the Console at all, like policy installation timeout). Same thing in this case. Tomorrow I'll try messing up with the thing a bit more and then ask for a TAC case if nothing changes (we're going through a third party for this customer, quite a mess...).

[Bob_Zimmerman]

The cluster_object references are a side-effect of how VSX works internally. A VS on a VSX cluster is actually a cluster object made up of one VS member on each physical VSX member. The GUI hides this, but if you look at the object database, that's what's going on. Those references get handled automatically when you delete the visible VS in the GUI.

The rule_base reference is the concerning one. Do you get any more detail if you find the VS UUIDs (cluster and all members) and search for them with 'mgmt_cli -r true where-used uid "<UUID>" details-level full'?

[S_K_S · Accepted solution]

Turned out that this was the cause. 🙂 I just disabled all extra security blades  and also found that the VS was an installation target for a Threat Prevention policy and removed it from there. So even though the policy package was detached, it still was a valid target for installation and possibly also some "default" policy related to additional blades. After clearing all this the deletion succeeded. Would have been nice if "Where used?" could deliver less ambiguous results but at least all is fine now. 

[genisis__]

Glad to here it was one of the suggested things to check, and nothing more serious.

[JozkoMrkvicka]

I am wondering if API will show more info where object is used as is seen in GUI... As far as I know, it should give the same results (what is output from API is the same as seen in GUI). Maybe "details-level full" is doing the magic ?

[Bob_Zimmerman]

I don't actually know if it would show more information. I suspect the GUI tries to show certain properties from the results, and a Threat Prevention policy may not have the exact property, or the exact path to the property which the GUI is trying to show. The API makes less of an attempt to pretty things up for display, preferring instead to show exactly what it has in the way it has it.