# How do I migrate Elasticsearch Data Nodes by Moving Virtual Disks Between VMs **URL:** \ **Category:** Elasticsearch\ **Created:** [June 26, 2025, 3:21pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539 "2025-06-26T15:21:20Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![KimuDesign](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@KimuDesign](https://discuss.elastic.co/u/KimuDesign)\ **Post date:** [June 26, 2025, 3:21pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/1 "2025-06-26T15:21:20Z")
Hi all, I have a production Elasticsearch cluster v 7.10.2 with 4 data nodes and 3 master nodes. Most of our indices have 4 shards and 1 replica. We perform a rollup of indices nightly at 3 AM. I’m planning to migrate each data node to a new OS by deploying new VMs one at a time. The data disks are virtual disks in our hypervisor environment, and my plan is to detach the virtual disk from the old VM and attach it to the new VM hosting the new OS. I have a local tiny cluster that I've been trying to test the behavior on, but I'm still a bit scared. Is there anything that could go wrong? Is there a better way to do this? ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [June 26, 2025, 4:15pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/2 "2025-06-26T16:15:18Z")
Just to be clear, the new VM will be given same node name/IP as that which it will replace? You **must** ensure the virtual disk is never mounted on 2 VMs at same time. There’s a few different ways you might approach this, it’s more of a matter of sysadmin taste which they prefer. You are taking right approach to test on a small non-operational cluster first. ---
**Author:** ![KimuDesign](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@KimuDesign](https://discuss.elastic.co/u/KimuDesign)\ **Post date:** [June 27, 2025, 8:42pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/3 "2025-06-27T20:42:45Z")
@RainTown Thanks for looking into my issue! I’m aware of mounting and have some experience migrating disks between VMs. My question is: what issues could arise if one of the four nodes disconnects and then comes back online after 1–5 minutes? Will the indexes be affected in any way? ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [June 27, 2025, 9:12pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/4 "2025-06-27T21:12:56Z")
Well, cluster state will go yellow, shards change state (replica/primary), move around (preventable), clients might see transient errors. All of these , and others, are manageable. Whether those are “issues” is semantics. Whatever node you are working on will (likely) contain some indices’ primary shards, and replica shards for other indices. Those shards would be unavailable. You didn’t answer the question: > [@RainTown](#): > > Just to be clear, the new VM will be given same node name/IP as that which it will replace? If yes, experience _should_ be similar as when you have applied OS patches and rebooted, or upgraded cluster software version. ---
**Author:** ![KimuDesign](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@KimuDesign](https://discuss.elastic.co/u/KimuDesign)\ **Post date:** [June 28, 2025, 9:46pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/5 "2025-06-28T21:46:28Z")
Yes, the machine will get the same hostname and IP address. I was planning to do the work before the moment when the new indexes are created, so that the new indexes would already start writing into the cluster that consists of all the nodes. How can I reduce the time the indexes stay in yellow status and time of shards unavailable? ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [June 29, 2025, 11:48am UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/6 "2025-06-29T11:48:31Z")
You probably want to disable , or tune, shard allocation for short periods. I’d likely NOT do this operation near time when new indices would be created by an application or ILM policy or … Again, if your prep is good this isn’t a difficult task. You are cautious (good!) and asking right questions. You have a test cluster to tune the process. The risks are mostly on sysadmin error side, wrong permissions, not matching UIDs, duplicate IPs, etc. if you avoid these it’s not much different than a node rebooting. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 29, 2025, 8:56pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/7 "2025-06-29T20:56:55Z")
> [@RainTown](#): > > the new VM will be given same node name/IP as that which it will replace? This doesn't really matter much. If you attach the disk to a new node with a different name or IP then Elasticsearch will work out what to do. > [@KimuDesign](#): > > How can I reduce the time the indexes stay in yellow status and time of shards unavailable? Follow the [instructions in the reference manual for the rolling restart process](https://www.elastic.co/docs/deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures#restart-cluster-rolling). ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [June 29, 2025, 8:57pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/8 "2025-06-29T20:57:58Z")
> [@RainTown](#): > > I’d likely NOT do this operation near time when new indices would be created by an application or ILM policy or … Again, this shouldn't really matter. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [July 3, 2025, 7:09pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/9 "2025-07-03T19:09:23Z")
Did you make some progress? Do you have further questions? ---
**Author:** ![KimuDesign](https://avatars.discourse-cdn.com/v4/letter/k/bcef8e/32.png) [@KimuDesign](https://discuss.elastic.co/u/KimuDesign)\ **Post date:** [August 7, 2025, 1:06pm UTC](https://discuss.elastic.co/t/how-do-i-migrate-elasticsearch-data-nodes-by-moving-virtual-disks-between-vms/379539/10 "2025-08-07T13:06:24Z")
@RainTown @DavidTurner I successfully migrated my cluster using disk switchover in hypervisor. Yes, there was some downtime for part of indices, but not for the entire cluster. Thanks everyone for your help.