So CP documentation says that the DMS/CMA for the physical VSX gateway should be different than the DMS/CMA for the VSs themselves.
Which makes sense. You really should do this because when it comes to:
1) Assign permissions to your DMS, you want the super duper admins in charge of the
physical chassis and the sub-humans in charge of the regular VSs.
2) Decommissioning: One thing the I feel CP sucks at is deleting and moving and renaming objects. Either you can’t (GLOBAL OBJECTS), or if you do you get 1000 errors and you have to GUIDBEDIT from 1am to 7am on a Saturday morning with huge sweat stains in your armpits. If you decide to decommission a VSX physical gateway, you should isolate it into its own DMS. and put the VSs in another VS. That way its easier to delete and re-create…..even if the whole thing blows up.
So How does this all work???? Well the basics are the physical chassis goes into 1 CMS/DMS and the VSs go into a separate one.
So first create the VSX gateway in one CMA/DMS. Like here you see I created TestGW into the HQ_Domain CMA/DMS
So any policy will only be adminstrated from the HQ domain admins.
They I create Virtual Systems, in the HQ_VSs_DMS CMA/DMS that reside in the TestFW physical VSX gateway:
So you can see that the VS was created in a separate DMS.
So now the part that sucks is that the MDS does not really track in a hierarchical manner what VSs are related to what VSX gateways. As you can see above the Test VS is not under the TestGW. Duh.
I’ve written the P1 developers about it. Supposedly the new wiz bang P1 will cure cancer and grow hair on my head and solve this problem, but I’m not holding my breath. I’ll give it until 1/1/2015 until all the bugs are worked out until I see it solve this problem.
S
But only a week ago I was drinking wine and eating baguettes and cheese at my campsite. What was I thinking?
Firewalls Rule!
dreez
DreezSecurityBlog 