During the last days I've spent some time developing my own procedure to resize the /opt partition of my Web Gateway (virtual appliance) without the necessity to install and configure a new one from scratch (as McAfee Support has suggested).
Our problem was in the initial definition because the vmware virtual machine was created with a virtual disk of 30 GB. This cause that the appliance (after some months) begins with updates issues (stopping URL Database Updates processes) due insufficient disk space.
From Mcafee Support side I received this response:
“The /opt partition currently only has 4 gigs of hard disk space. Requirements for running MWG on vmware include 200+ gigs for disk space which would then give the opt partition 40gigs to work with.
I would recommend building a new vmware appliance that meets the requirements and then joining it to the cluster so that the configuration can sync.”
I agree that the requirement is 200 GB (which is correct and is documented) but I think that McAfee Support can give me another solution to solve my issue.
Among other things, I have moved to a virtual infrastructure due the easily provision of the resources (as needed). So, I did my effort to find the correct way to solve this issue and take the advantage of the virtual infrastructure.
The procedure (based on VMware KBs, Web Gateway Community and Linux LVM commands) is available for anybody, but as I do not have the appropriate permissions to upload a document on the community I decided to write this post. If someone wants to get the procedure send me a private message.
No need for your own procedure, you can run the resize script after the fact. If you resize it to the "alternate", you cannot resize it again though, that will require a reimage.
Hi Jon, thanks for your reply.
DOC-5195 is for cache resizing and only works when you have storage available. With this procedure you reduce /cache size and then increase /opt partition size, but you must have the storage available to do it.
My situation was:
/dev/mapper/vg00-opt 3.9G 2.9G 817M 79% /opt
/dev/mapper/vg00-cache 992M 695M 298M 70% /opt/mwg/cache
If you only follow DOC-5195 you alternate /cache and /opt partitions size. In my case didnt solve my issue because the disk size was very small and there was insufficient space to allocate.
With my procedure you can create a new partition, extend de logical group, mount /cache point and extend the size of the disk. After that you can follow DOC-5195 to alternate partitions size.
The built-in partition resizing feature doesn't offer a lot of flexibility.
I have documented how to take a base MWG installation with a large /opt/mwg/cache partition, reduce the cache partition size and reallocate the space to the overall /opt partition. Not precisely the same as cfalero's solution since mine assumes that the space is already available and no new partitions are necessary.
If anyone wants the procedure, feel free to PM me. NOTE: this is not sanctioned by McAfee and if you experience problems with the procedure you are likely out of luck. What I can say is that it's been executed on over 2 dozen MWG 7.2.x systems with no issues.
Just to be sure that everybody who reads this is aware of the feature mentioned in here - we provide a shell based tool: mwg-cache-wizard that allows you to essentially swap cache against /opt. With that you get more space on /opt at the cost of a reduced cache.
Both resizing the disks and rebuilding the VM take me about 20 minutes using Backups. I dont really get why you would want to use a process that would potentially leave you with out support.
Even bare metal rebuilding using the OOB interface for the 5000 and 5500 servers takes a similer amout of time.
I have a deep-seated dislike of my systems running out of space in any given partition.
/opt is used for logs, temp files, etc.
The mwg-cache-wizard tool introduced in 7.3 offers additional flexibility in terms of partioning and if that layout works for you, that's great.