why change a running system only if the power supply fan is defect? Cleaning the hardware will help or change this fan will be for me the best situation.

I think there is no maintenance after 3 years on the hardware!

You have a stable gw on a sles15sp5 server, this is a good operating system!

Would you want to change the os for gw to windows? or only a virtual machine on a MS-Server?

You are correct. I intend to keep the old hardware running and have a used power supply of same model I can swap in if needed. Just trying to think ahead and perhaps cut overall power expenditure (old hardware draws a lot of wattage compared to newer hardware).

I would put the VM on a MS-Server. MS-Server I have on hand would easily handle another VM.

While a P2V (Physical to Virtual, to Hyper-V it appears in your case) is possible, sometimes it is actually easier in some situations to just build a new vm from scratch, and move the data/app over.  With GroupWise, this is so easy, it may well be the best option to move forward off of that old hardware.

You can build the new vm with a different IP, and at the final switch point, you add a secondary of the existing GW system for it to use on the new platform.

I have done a few of this sort of migration recently (older to newer OES, vmWare to Hyper-V), so have some notes on it that I'm aiming to share. (so this might be the kick I need to finish that ;)

By any chance was this box built with SLES 11 given the vintage of the hardware?  If so, you get the 'fun' of the Baroque BTRFS, where you will need to double the space of your root drive, and must not use that file system for GroupWise (or eDir) but another drive of XFS for your GW data. 

Yes, SLES 15sp5 is a solid base, so hopefully the OS underlying the vm doesn't give you too much grief.

I have the same experience with moving Groupwise. It is mostly easier to move Groupwise from one machine to another new (virtual) machine, than to migrate the whole machine to another (virtual) fabric. And a freshly installed OS is always much more "clean" , than a migrated OS. Further you can change the OS, if you install a new VM and Groupwise does even run on Windows - but that may be expensive in terms of license costs.

To Andy: What I would be interested in the mentioned migrations is the experience with migrating Groupwise from Vmware to Hyper-V. Are there any negative drawbacks after such a migration and what OS did you choose for Groupwise under Hyper-V?

Regards

Hi Wolfgang

This client stayed with OES, just going to the newest version on the new boxes. I didn't really see the hypervisor levels and barely saw the OES details as I mostly just walked them through the process on this particular set of migrations (one left to go). They had experience with Brodcom acquisitions before, so hearing about them in the process of acquiring vmWare, they started their Hyper-V path.  I was brought in for just the GroupWise and email flow specific parts. I haven't seen any big issues that made it to my attention.  

I like your idea of creating a fresh vm and moving over data. Hardware originally had SLES 11, but a few years ago, I put a new hard drive in, install SLES 15, and copied over data (basically as you describe for VM) and worked beautifully. I like XFS on this hardware. 

If you stay on same DNS/IP values, do not forget to copy certificates too. It makes life easier 

I have many years of experience with the tool here: www.microfocus.com/.../platespin-migrate. I have migrated GroupWise systems from physics to various hypervisors for customers. These included systems that had more than 1000 users per PO and the whole thing was running. The downtime of the systems was less than 5 minutes because Platespin adapts everything to the new platform, on Target ist only rcgwstart nessesary, GW will start.No matter how complex the GroupWise is, whether it goes over several servers, is an HA cluster, Platespin can help to go from A to B

For OES server migrations from physics to hypervisors, the thing is also a blast, I have also moved OES servers from VMWare to Openstack in this way. 'NSS is not an issue, it also works during operation. Backup, recovery, replication, migrations from A to B have been my world for many years. Platespin is really a tool that I have come to appreciate.

Of course it takes practice and knowledge how to handle Platespin. Today I think it is important to know such tools because they can also help to move systems to the cloud. I won't talk about the sense of it at this point

In connection with Platespin, it should also be said that VMware can also be migrated to Nutanix, KVN, XEN, Hyper-V or whatever. It is also possible to swap partition types and from EFI to Bios or vice versa. In the field I once had to bring Hyper-V with MS SQL allways on HA including SAP HANA installed on it (HCI was the whole thing) to openstack. The hypervisor had not yet mapped EFI in openstack at the time. From that time I still have scripts of the stripped drivers from the boot partiton of Windows and put them from Openstack into the VM. If you know what kind of magic it is when the drivers are signed, you can imagine what a dance it was. I did the same with the kernels and kernel drivers for Linux systems.  

So if there is a need to go from VMware or Physik to xyz. It is possible with the help of tools and also by hand.

SLES 15 SP5 is a stable System for GroupWise. In any case, note how the partitions / disk and which driver model is to be used and, above all, note which file system is used for what. Using BTFRS for GroupWise is a no go. In the case that an operating system change is planned for the operating system on which GroupWise is installed, it must of course be reinstalled. However, there is also the option of using rsync to move the GroupWise data and certificates from a to b. This is possible for the first sync during operation.

DH2 said:

I like your idea of creating a fresh vm and moving over data.

Hi David,

This is also my preferred method. 

When upgrading an old(er) OS the upgrade process tries to maintain compatibility with what you already have put in place. After a series of such upgrades, issues can surface. When your OS is running on physical hardware it is a lot easier to do an inplace upgrade than a fresh install. In a virtual environment my rule of thumb is always start with a fresh install and migrate unless there is a good reason not to.

To simplify future migrations, I always install my GroupWise data (domains, post offices, ...) on a dedicated virtual disk. I also like to attach that virtual disk to the VM using a dedicated storage controller.

You didn't say how much data you have. Often the most difficult (or time consuming) part of the migration is transferring the GroupWise data. The traditional way is to use DBCopy to transfer data from your live GroupWise system then do a final copy after quiescing online activity. When running in a virtual environment, other options are available.

I prefer to make a virtual copy of the source disk, attach that virtual disk to the new VM, then use the Linux cp command to transfer the GroupWise data from the source virtual disk to the destination virtual disk from within the new server without requiring a data transfer across a network. I find this approach to be very reliable and very fast. In your case, all you would have to do is a PtoV of the drive on your current SLES server containing your GroupWise data.

Thanks much Kevin and all responders. Excellent advice. It is great to have so many flexible tools and options. This is a great forum.