Skip to main content
Question

Red Hat Linux VM's OS version issue

I have multiple VM’s of Red Hat Linux OS.

And in our environment, VM backups are configured at vCenter level.

Our server team did OS upgrade from Red Hat Linux 7 to Red Hat Linux 8 (In place upgrade of OS).

Even when new VM backup ran for the servers, the OS version is not changed to Linux 8.

Do I need to delete VMClientDB file from all VSA proxies to rediscover the latest OS version of the VM’s?

Or anything else.

Please help me out here.

10 replies

J
Rank
Badge +1

Typically discovery should do this.

I would firstly make sure that you’ve refreshed or re-opened the Commcell console/command center. If it still hasn’t changed, then I would suggest selecting to refresh VM status under Refresh Datacenters for your VSA pseudoclient.

Refresh Datacenters (commvault.com)

K
Rank
Badge +5

Hi Jace,

I had checked with my server team and found that the server are upgraded to 8 when checked in the server, but when checked in vCenter, the servers OS still shows the old version which is version 7.

I asked my server team to check with VMware team.

I guess this might be the issue, as our backup are configured at vCenter level and Commvault is fetching the details from vCenter, i guess as the vCenter is not updated, our Commvault is also not updated.

I guess refresh need to be done at vCenter.

J
Rank
Badge +1

Hi Kiran,

That would explain it. As Commvault is backing up from a host level it isn’t looking at the OS itself, just the blocks of your VMDK so Commvault relies on VMWare to provide accurate OS information. If VMWare isn’t up to date then Commvault won’t be either.

Once you are able to update on the VMWare side you should see it reflected by the next backup in Commvault.

Ralph
Rank
Userlevel 2
Badge +6

Commvault is reading these settings from the vCenter:

 

If these settings are wrong, well...

K
Rank
Badge +5

Hi Jace, 

 

Thanks for the update.

@Ralph The Linux servers are in version 7, but server team did an in-place upgrade to version 8. And it seems its not reflected at vCenter. I guess we need to edit the config file as you showed in the above screenshot.

 

@Jace Ross Let says if we didn’t change the config file and let the vCenter show the OS version 7, Will this impact our backup and restore functionality? That is crucial point that I need to know.

Let me know if this will impact the backup and restore?

 

Thanks

Kiran Kumar

J
Rank
Badge +1

 

@Jace Ross Let says if we didn’t change the config file and let the vCenter show the OS version 7, Will this impact our backup and restore functionality? That is crucial point that I need to know.

Let me know if this will impact the backup and restore?

 

Thanks

Kiran Kumar

Recoverability will not be affected.

Commvault VSA operations are, largely, not concerned with the guest OS. The focus is to protect the VM disks and configuration files so the information about the guest won’t affect that.

K
Rank
Badge +5

@Jace Ross 

So file system, DB backup, VM backups will not have any issue?

And restore also will not have any issue right?

 

 

Thanks

Kiran Kumar

Alex Deaconu
Rank
Userlevel 2
Badge +4

That is just a VM label when the VM was created. I am not sure if you are able to change it, but it should not matter, as it should not impact the backups.
 
If it is too annoying visually, power off the VM, Edit Settings on the VM, and change the Guest OS in the General Options.
 
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-3B66132C-F3E7-4F86-836F-80A03AC99E2A.html

K
Rank
Badge +5

@Alex Deaconu Thanks for the update.

I will check with my VMware team and see if we can change.

 

 

Thanks

Kiran Kumar

J
Rank
Badge +1

@Jace Ross

So file system, DB backup, VM backups will not have any issue?

And restore also will not have any issue right?

 

 

Thanks

Kiran Kumar

DB Backup and File system is a different story as they are running within the OS but those agents should identify the correct OS as that check is made with each job run.

Reply


Terms & ConditionsCookie settings