Starwind V8 upgrade feedback

lohelle · Wed Jun 25, 2014 2:56 pm

Hello

I was wondering if many of you have upgraded your production systems to Starwind 8.
Did you have any problems with your vSphere environment after the upgrade? I remember testing the beta in my home-lab, and then vSphere found the LUNs as new drives (had to unregister and re-add all VMs), and then we had to run full backups again (Veeam).

I had hoped to power off the VMs, adjust the timers for APD (all paths down) and PDL, and do the install as documented. I have previously also upgraded without shutting down all VM's (just databases, Exchange etc), and just very quickly doing the service-interrupting node2-upgrade (major version upgrade). When blocking user-traffic in the firewall, normal servers handled 1-2 minutes of storage downtime just fine.

Comments?

kmax · Thu Jun 26, 2014 5:12 pm

This is a hyper-v environment so take it for what it is worth. I just basically do straight HA, no dedupe or other stuff. Just basically HA images.

I basically did a damn the torpedoes type thing and shutdown the starwind service on one of the nodes. Then upgraded a starwind node to V8. It resynced quite quickly after the reboot. After the resync I did it for the other node. Again another fast resync. All VM's kept going happily along.

I was quite impressed actually, because normally this would trigger some sort of full replication in the past. And they felt a little bit snappier after it all happened.

Now with that said, here's the thing. My backup times (using backup agent inside the VM's) are taking around 30% longer now. I haven't said anything as I'm still fooling around to see what's going on. But that was the only thing I changed...was the upgrade.

lohelle · Thu Jun 26, 2014 8:45 pm

Thank you for the feedback. It would be great to do this type of upgrade, but I'm afraid of the same error as with the beta upgrade (home lab).
I would have to force kill and unregister all VM's, import/resignature all LUNs, import all VM's, and then recreate all backup jubs (with the extra bonus of full backups to the remote site...)

It would not be pretty, to say at least...

Feedback from vSphere upgrades would be nice.

Fri Jun 27, 2014 11:40 am

Brrrrr... Why have you to kill VMs? What happens when you put one of the storage siblings down? Is it performance drop or... ?

lohelle wrote:Thank you for the feedback. It would be great to do this type of upgrade, but I'm afraid of the same error as with the beta upgrade (home lab).
I would have to force kill and unregister all VM's, import/resignature all LUNs, import all VM's, and then recreate all backup jubs (with the extra bonus of full backups to the remote site...)

It would not be pretty, to say at least...

Feedback from vSphere upgrades would be nice.

lohelle · Fri Jun 27, 2014 12:20 pm

During the beta-test, I upgraded my home-lab (real server HW). I upgraded, and the ESXi hosts found the LUNs as NEW LUNs.
To fix this, I had to unregister all VMs and readd them, AFTER I imported the VMFS partitions (resignature).

If the same error was to happen, it would be a disaster. Even if all VMs are powered off first, first I would have to readd all VMs, all backup jobs, resource pools etc will have to be recreated (a few 100 VMs). And as mentioned, all remote site backup-jobs will have to run as "full backup" again, and not incremental as normal (first pass)

Wed Jul 02, 2014 8:34 am

Well, that is why people usually put the production on the Beta versions of anything - to get some headacke

Our R&D confirmed that eople will not face such issues during upgrade from one release build to another.