This is coming but availability has not been announced yet.

Indeed not possible right now. Only new CommCell environments can be setup with a Linux based CommServe. Migrations are expected to come in the future, but I expect this may take a while before this arrives. 

hey guys,

I’m wondering what the ETA is on this as if it were not for the CS needing to be on Win, I’d have no need for any such OS in our mgmt plane (we’re 95% *nix shop). The amount of work required to manually recreate “the wheel” by building an entirely new CommCell just to get to this point is a month-long project at best (for each CommCell).

I do understand (or try to) the incredible complexity of what dev must be facing to port the DB’s and such to Linux, but for those of us knee-deep into fairly complex environments, anyone can see the rub with not being able to just “migrate”, or, ideally, failover to a cross-platform CS standby, rebuild, failback, however it’s pulled off.

Even if 80% of the stuff could migrate (not data, but configuration, plans, etc.) that would be enough for me and probably plenty of other customers to say “ya, let’s try it”. For instance, the “upgrade” installer could tell you “hey, you are not going to get 100% of your configuration by doing this, click OK if that’s fine”. 

Is there a “secret NDA decoder ring” whereby dev and a VAR could facilitate the migration? We have a very short window where several new MA’s and stores are being built, but this doesn’t help get all the clients or schedules over. Once this window is passed, it’ll be a long time before we can even consider taking the time to rebuild it all under a nix CS.

thanks

@downhill, this isn’t something I (or anyone else in Support) is going to be able to comment on. Your account rep may be the best avenue to ask these questions, and I don’t know what they’ll be able to tell you either.

I have asked our team. Lots of silence. Any one tried out the Cross platform ( Prod Commserv in windows and stand by in linux) Commserv live Sync | Community (commvault.com)

This is the post that led me here to re-ask. MFasulo - I would have to imagine there’s a substantial list by now? I could send an email but I’d think over a year there’d be an ETA for this?

thanks guys

Hi @downhill 

I have performed a test so there is no guarantee that all works as expected.
Seems to work so far 

NOTE: This is not a Commvault approved/supported method.
All actions are for a persons own risk if they want to duplicate this.

Prerequisites:

• Linux server must have same hostname as Windows server
• Linux server must have same IP as Windows server
• Linux server must be able to resolve it's own hostname / shortname
• Supported Linux OS, dependencies and configurations as described in Documentation

Things to keep in mind:

• If your Windows Commserve also acts as a Media Agent with a DDB you will need to perform extra steps, these steps are not described extensively here, just the Commserve part.

Step 1: Create a DR Backup from on the Windows Commserve and shutdown the server

Step 2: WinSCP the DR Set to the Linux Server
I performed CHMOD 0777 recursively on all content

Step 3: Download Linux Media Kit

Step 4: WinSCP the Linux Media Kit to the Linux Server
I performed CHMOD 0777 recursively on all content

Step 5: Start the installer ./cvpkgadd as root from the location where you allocated the installer

Step 6: Select “Install packages on this machine”

Step 7: Select “Create a new CommCell”

Step 8: Select the interface which is primary for this server, this is the interface with the IP used on the Windows Commserve

Step 9: Select “Server Components”

Step 10: Define the location for the binaries folder, in my case the default /opt

Step 11: De-select the option “Create new database instead of restoring from database dump

Step 12: Enter the path where you allocated the DR backup

Enter 13: Follow the remaining steps:

Result:

Java GUI working and all information visible:

Command Center working and all information is visible:

As I was also running a MA on this server I had re-allocate the DDB (needs Logical Volume and max 90% space in use) and the Disklibrary, then correct the paths for these configurations and enabled the media agent.

Ran “Update CommServe for Clients (use this option after DR restore)“ for the clients which are directly connecting to the Commserve.

Then successfully performed a test backup on my laptop which is connecting to the Commserve via a Commvault Gateway Proxy:

Wow, that looks promising. The support teams will not like the name being required to stay the same but I could see making that fight. 

If I was planning on re-IPing the CS and standby’s, if taking this route, I’d have to do that all before “migrating” I take it, or is re-IPing the CS post restore also valid under Linux?

thanks!

Hi @downhill 

The requirement regarding the IP address is due to the license which is being checked during the DR import. If the IP is different during the import you will need to provide a new license file based on the new IP address.

I have not checked yet if I can change the IP up front or afterwards, will let you know when this has been tested.

Hi @Jos Meijer I am finally getting back to this effort of migrating to Linux CS, we had some delays and priority issues, etc.. The thing is, the new RHEL8 box had to be built on a new VLAN using their naming convention, so, the CS physical name and IP will be different than the current one. I am wondering, since I can’t seem to find an article that speaks to it, whether the procedure would be to setup LiveSync from the existing Win CS » RHEL CS and then promote, or if just doing an install but importing the old DR backup/DB into the new machine would work? Essentially taking care of both the SQL DB upgrade as well as eliminating the older Win CS’s. Do you guys have any direction on this yet? My plan is to go to 11.32 unless 11.34 has this sort of “upgrade” process well supported.

thanks!

FWIW, I went from Win 11.32 to Linux 11.32 doing a fresh CV install w/ CSDB import.

Thanks,
Scott
 

Hi @downhill 

As @Scott Moseman said, the import works.

I am interested to the failover between OS types though… will see if I can validate that.

@Scott Moseman what I was trying to avoid was upgrading the Win CS (which is running Server 2016 and older SQL) from 11.28 to 11.32 but take care of that entire upgrade as part of the import. That would save some time but maybe not feasible. I also wasn’t sure if messing around with the fresh install, setting up replication, etc. was worth the trouble as the old one will be rebuilt too, but maybe there is no alternative. thanks guys

Hi @downhill ,

When using the CSRecoveryAssistant the CSDB will be upgraded if needed.

This mean you should not need to update your previous WinCS to FR32. Providing the FR28 CSDB when importing it back into the LinuxCS should also run the upgrade process for it.

It will be a week before I can try this but sounds like a plan! thanks guys

This process does indeed work slick. Just wanted to confirm.