StarWind Software

I can understand now why the repo for Proxmox went offline - there is a new VHCA available.
I did find an old upgrade procedure from May 17, 2024 (https://knowledgebase.starwindsoftware. ... chine-cvm/) is this still relevant?
I can see the Update button but don't want to click it until I know whether I need to migrate/shutdown VMs on the Proxmox host of the VHCA?
Does the existing Starwind LVM plugin work with the new VHCA?
For Proxmox the release notes state "Added rescan script to connect StarWind devices at Proxmox VE boot." is this different to the current script?
How is this installed to the host and where do I get it?
Does it prevent the open-iscsi.service from timing out when a Proxmox host is rebooted?

I did find an old upgrade procedure from May 17, 2024 (https://knowledgebase.starwindsoftware. ... chine-cvm/) is this still relevant?

Yes, mostly yes, but I want ot boil it down and add some details I feel are missing there.
1. Make sure StarWind HA devices are synchronized.
2. Make sure they are connected from both nodes to all Proxmox hosts.
for each Proxmox node do
iscsiadm -m session
3. Hit update for one node.
4. Wait for the update to finish
5. Wait for replication to finish.
6. Repeat 1-5 to the remaining node(s, one at a time).

Does the existing Starwind LVM plugin work with the new VHCA?

LVM plugin lives in a separate world and mostly targets Proxmox, not StarWind VSAN service.

For Proxmox the release notes state "Added rescan script to connect StarWind devices at Proxmox VE boot." is this different to the current script?

You can leave the current script in place.

Does it prevent the open-iscsi.service from timing out when a Proxmox host is rebooted

No, that script targets mostly iscsiadm -m node -r, not the timeouts, AFAIK.

Thanks for the information, I'll update the VHCAs over the next few days and report back on my experience.

Keep me posted. Thanks for sharing!

The upgrade was pleasantly uneventful. I updated one node then confirmed that all disks had synched and then updated the next node.
Everything worked as it should and I haven't had any issues.
I look forwards to repeating the process when the next version is released.
In the unlikely event that the next version is pulled and I encounter an issue what is the recommended procedure to rollback to the previous version?

Thanks for your update!
Sadly, we are still drafting the roll-back procedure.
As of the update, I think it should be released next week. I think it might be a good idea to wait for a month before updating if the system is in production.

Ok so the one approach would be to shutdown each node and duplicate the virtual disk before attempting to upgrade?
Or alterantively just use Proxmox to backup each node and do a full restore if the update fails?
Any comments on those ideas?

hi,

Yes, it might be a way to go. That's a very valid point.
1. Make sure that the restart prerequisites are met.
2. Shut down one CVM.
3. Detach the storage (e.g., QUEMU device, pass-through device, or RAW image) that keeps StatWind Images.
4. Back up. You can just copy the OS disk, true.
5. Attach the disk back (for multiple pass-through devices or disks in general, order matters).
6. Start.
7. Wait for fast sync to complete.
8. Repeat for another VM.
9. Update according ot the general update procedure & test.

Ok thanks for the detailed steps - lets hope they never have to be taken.

Actually, a snapshot could be enough.
But I am just too worried about snapshots in general.

It 's annoying being paranoid and taking more time just in case BUT far worse is being just a bit too casual and have that sinking feeling of there goes my weekend why wasn't I more careful?
I have experienced both the relief of a good rebuild and restore and the terror of a failed restore and "Oh my God please help me". The early terror inspired more make sure you can go back if this doesn't work.

Yeah, I had a lot of fun with snapshots while fixing what others had done to their systems.
So, I'd rather walk an extra mile here.
Thanks for reminding me about the workaround for a rollback.