CSCvv60842 - DOC - 9800 disk space change from 8GB to 16GB when upgrading to 17.3

[rrumney]

Maybe somebody can shed some light on this. This bug report says upgrading the 9800-CL to 17.3 on 8GB of space for the VM is not service impacting and only affects logging. However, CSCvw08276 makes no such claim and just says to redeploy the VM.

Which is correct here? I've been through the release notes and they explicitly state:

"From Cisco IOS XE Amsterdam 17.3.1 onwards, Cisco Catalyst 9800-CL Wireless Controller requires 16 GB of disk for new deployments."

"If you are upgrading to Cisco IOS XE Amsterdam 17.3.x from a previous release, resizing of disk space is not supported. If the current disk space is lesser than 16 GB, you need to redeploy the VM to meet the new disk space requirements."

What is the actual correct information here? There's no mention anywhere else that I can find that you can run 17.3 on 8GB of disk space and not have any downtime.

[christian.hoehn]

We upgraded a C9800-CL to 17.3.1 (SDA fabric integrated).

After the upgrade we had the described Syslog entry: %EWLC_PLATFORM-4-REC_DISK: System is running on a disk lower than recommended.Current Disk Size: 8GB, Recommended Disk Size: 16GB

We recognized no downtime. The WLC was running without any issue.

This is not a recommendation to do not a fresh deploy of this WLC VM but it's a fact that there was no issue with this environment except the syslog message.

[rrumney]

Thanks, that helps a little bit. We're staying on the 16.x release for now. I'm hoping Cisco figures something out for this as redeploying controllers is not a good solution. It was a complex process to get certificate authentication to work as well as AD authentication working in our environment, adding in having to migrate APs to new controllers is just too much for what should be routine software updates as eventually the 17.x branch will be the suggested release.

[christian.hoehn]

That I hope as well, told the TAC engineer about our customers having different 9800-CL WLCs, if we've to redeploy everyone of these, that would be a story....

If ther is a DNA Center controlling the configuration of the WLC, the problem isn't as big. You could setup a secondary WLC and change it to primary and you'll have the whole wireless config pushed from DNA Center. But if not, you will have to reconfigure the whole settings.

Maybe there is a possibility: upgrade the controller to 17.3.x, take a backup and restore it on a new deployed one with the same version. Then delete de old upgraded one.

[rrumney]

I think you may be on to something there. I'll have to lab it up and test it before doing anything in production, but I may be able to do something similar with the 16.x branch as well. I could try deploying a controller through the ISO deployment method where I can specify the size of the virtual disk when I build the VM. Then restore a backup of the smaller controller onto it.

[jbemp]

RRumney, We are about to go down the same path. Were you able to deploy a larger VM and then restore to it?

[christian.hoehn]

Did this several times: Deploy new larger VM and restore it from the old VM.
Never recognized problems doing like that.

16.12.x --> 17.6.5 (for an example)

[jbemp]

Was the new larger VM the same version? Then after the restore you ran the update? Or was the new larger VM the new version? Exp old vm 16.12, new vm 16.12 then update to 17.6.5?

[rrumney · Accepted solution]

What we ultimately ended up doing was deploy a new 16.x vm with the larger disk space, restore the config and certificates, and then after confirming all was working, we did the in place upgrade to 17.x. While on paper it should have worked, I didn't like the idea of restoring across different software versions in production so we went the 16.x to 16.x route and then upgraded to 17.x normally.

[christian.hoehn]

There was never a problem recognized doing a restore across different version (16.12.x to 17.6.x). No problem, you could do that.

Maybe there are some commands which are marked as deprecated soon. You'll find these in the logs.

[christian.hoehn]

No, the new larger VM was directly deployed using an OVA template of the new version. No update needed.