Notifications
Clear all

VM 'Offline' Issue with vCenter Storage DRS


Reece
(@reece_scholar)
New Member
Joined: 2 months ago
Posts: 2
Topic starter  

Hi All,

We have noticed an issue when a VM has backup enabled and is migrated to another datastore, that VM will then appear offline in the Pure web GUI and Pure will re-discover the VM that has been moved, as a new VM.

This causes the VM to not be backed up at all, as the previous instance appears offline, and the newly discovered one is not set to backup by default. This causes an issue when a large number of VM's are automatically moved with storage DRS and manual intervention is required to make sure these VM's are being backed up again.

We were wondering if there is any planned support for storage DRS, or any way to make Pure aware that the VM has moved rather than it thinking the original VM has been removed?


Quote
Marijan Kozic
(@marijan)
Member Admin
Joined: 2 years ago
Posts: 80
 

Greetings,

As you have correctly summarised, when a VM changes its datastore path, Pure will consider the new path to refer to a new VM. This is because internally Pure uses the VM path to uniquely identify a VM. Unfortunately, this means that it is currently not possible to fully support DRS and VM migration.

If you are determined to use DRS, you might consider making a compromise on backup speed and storage space and configuring Pure to automatically backup "both" VMs. Each time a VM changes datastore, a new VM instance will be created in Pure and the other(s) will be presented as 'offline' since Pure no longer finds them in vSphere inventory. If at least one backup has been performed on the active instance, it will remain in Pure repository until manually deleted. As the original VM moves across datastores, each time the corresponding Pure VM will become active. Pure will maintain a separate backup chain for each VM copy meaning that each incremental backup will include all the changes since the last backup in that same backup chain. E.g. if VM was on datastore1 on Monday, datastore2 on Tue and Wed, and back on datastore1 on Thu, and provided that each day a backup was performed, the incremental backup on Thursday will essentially include the changes that were already backed up on Tue and Wed again.

I understand that the above schema is less than ideal but if VMs do not move across too many datastores, it might be a usable workaround.


ReplyQuote
Reece
(@reece_scholar)
New Member
Joined: 2 months ago
Posts: 2
Topic starter  

Hi Marijan,

Many thanks for your suggestion. Unfortunately however, this is not an option for us as we would not want to back up every VM by enabling the auto-backup feature.

We were wondering if there where any existing plans to update the way Pure uniquely identifies VM's so that native support for storage DRS could be implemented, or if this could perhaps could be implemented at all?


ReplyQuote
Marijan Kozic
(@marijan)
Member Admin
Joined: 2 years ago
Posts: 80
 

@reece_scholar

I do not know if Pure will change the way the VMs are identified and when that might happen. Such change is not planned in the near future and I guess it would require a significant modification of the existing code.

That being said, I still think the above workaround should be somewhat usable if your VMs only move between 2 or 3 datastores. The first time that a VM (let's call it 'myvm_A') moves to a datastore, Pure will create a new VM instance ('myvm_B'). You then need to enable auto backups for that instance and perform at least one backup. This you only have to do once. When the VM moves back to the previous datastore, Pure will disable the 'myvm_B' and re-enable 'myvm_A'. The next backup for myVM_A will be performed according to the schedule and the only difference is that it will be slightly bigger, including the changes that occurred during the time that the VM was on datastoreB. If the VM moves back from datstoreA to datastoreB, Pure will again disable myVM_A and enable myvm_B. This time the myvm_B instance will be backed up according to the schedule without you having to intervene at all.

Obviously, this solution is far from ideal but if DRS does not include too many datastores, it might be good enough.


ReplyQuote
Share: