https://rancher.com/ logo
Join Slack
Powered by
Hi, we are planning to migrate vms from vmware to ...
# harvester
t
Hi, we are planning to migrate vms from vmware to harvester. Moving VMs from HPE SimpliVity (VMware vCenter) to SUSE Harvester. Instead of the standard two-cluster approach (temp Harvester cluster → backup/restore to permanent cluster), we're considering: Build a 3-node Harvester HA cluster on 3 rented servers. Import production VMs from VMware via the VM Import Controller. Validate VMs, then wipe our old SimpliVity (DL380 Gen10) hosts and join them to the same cluster (not a new one) as additional nodes. Confirm etcd quorum + Longhorn replica health across all 6 nodes. Cordon + enable Maintenance Mode on the rented nodes one at a time → live-migrate VMs off, evict Longhorn replicas, then delete each rented node from the cluster. End state: one cluster, fully running on the original (now-permanent) hardware — no cross-cluster backup/restore needed. can anyone confirm is this recommended approach ?
b
Recommended is going to be a strong term because there's so much that goes on with so many layers, that that's why you pay people good money to review all of your infrastructure and make those recommendations. Is your plan viable? Sure! Should it work, speaking in broad strokes? Absolutely! Can there be things that are true that will break your whole workflow? Yep! Off the top of my head... when you say "rented" How do you mean? Like co-located in your rack? VMs from somewhere? Do they match your CPU spec exactly? I kinda see this as your MOP: • Confirm etcd quorum + Longhorn replica health across all 6 nodes. • Cordon + enable Maintenance Mode on the rented nodes one at a time • live-migrate VMs off, evict Longhorn replicas • delete each rented node from the cluster.
Some of those things are kinda redundant, but they wouldn't hurt your Plan
A few things to note: If the rented nodes are a new gen CPU, it's likely that your live migrations will fail unless you do some tricky things with setting the CPU settings with kubevirt. Your backbone for longhorn/the nodes needs to be really really good to keep up with all the production traffic plus all of the longhorn migrations/sync. We had 100G bonds and for whatever reason volumes over 100/200G can take a really long time to shuffle around. You're talking about basically doing a whole other migration off the rented nodes and that'll take some time depending on how big those volumes are. It's not a deal breaker it just takes time. You might be able to shuffle some of that around if you're using a third party storage (Pure, Ceph, etc) because it's not moving replicas off your rented nodes to properly bounce them.
That might take even longer if the rentals aren't in the same switch with routing configured to hairpin correctly. I'd encourage you to test that.
So all three of the rented nodes are going to be etcd/control plane nodes as the first three in the cluster. Harvester won't let you put more than one of them into Maintenance mode at a time.
So you'll have to do them one at a time. (not a big deal, just time)
You can put them in Maintenance mode, then just delete them, and I think longhorn has a finalizer and it'll start to drain the nodes for you. and remove them when it's safe to do so.
You can manually trigger nodes and evictions on the other nodes but your disks are going to be screaming trying to do all the writes for the running prod VMs and creating new replicas, so make sure you have the iops, or just plan on taking it slower.
Deleting a CP node will automatically start a promotion of one of the other nodes as long as you pick the default install settings (or say they're management nodes)
🙌 1
Since they run etcd, make sure the boot disk is on solid state that can do the required iops.
Those are all the gotchas I can think of, but maybe others can think of some other ones. Good luck!
t
Sure Sir, Thanks 🙌
a
BTW: deleting nodes from the Harvester (k8s) cluster needs more attention, please refer this PR: github.com/harvester/harvesterhci.io/pull/114
5 Views
Open in Slack
PreviousNext
Powered by