Dear all,
at the Moment we have to give VMs IO Limits to prevent our Storage Systems to not to be unfair used by some bully VMs.
With the VMware Feature "Storage IO Control" and some Storage Policies to Limit the VMDK Disk IO we got some Problems at the end of a Veeam Backup Job.
Veeam Backup Starts -> VM Snapshot -> NetApp Storage Snapshot -> Deleting VM Snapshot -> Backup from Storage -> Deleting Storage Snapshot....
At the step "Deleting VM Snapshot" the IO Limits of VMware are active and on some "Special bully VMs" we get more OS IO than deleting IO for the Snapshot.
Does someone know this Scenario and can give me a hint if Veeam can modify the Storage Policy Prior and after the Backup Job or to Bypass the VM IO Policy for Snapshot removal?
Regards
TBL
-
- Service Provider
- Posts: 4
- Liked: 1 time
- Joined: Mar 05, 2019 4:54 pm
- Full Name: Tobias Blum
- Contact:
-
- Product Manager
- Posts: 6551
- Liked: 765 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: VM IO Limits and deleting Backupsnapshots
Hi,
Thanks!
Although there is no such option out of the box, you could try leveraging pre/post-job scripts for that.Does someone know this Scenario and can give me a hint if Veeam can modify the Storage Policy Prior and after the Backup Job or to Bypass the VM IO Policy for Snapshot removal?
Thanks!
-
- Service Provider
- Posts: 4
- Liked: 1 time
- Joined: Mar 05, 2019 4:54 pm
- Full Name: Tobias Blum
- Contact:
Re: VM IO Limits and deleting Backupsnapshots
Hi PTide,
thank you for your reply.
We haven't found any other solution so far and will proceed with your suggestion of pre/post jobs.
In the tests this option did the work really good and easy.
Unfortunately the jobs are run at the very beginning and the end of the job.
VMs will be unlimited for the whole copy job and only need to be while the snapshot removal.
Would be more smooth if the pre/post jobs could be more granular assigned to the job states pre and post the snapshot creation / removal.
I think another idea would be a Orchestrator workflow with some triggerpoints, but this would be a feature in the future and so far a bit erroneous perhaps.
Regards
TBL
thank you for your reply.
We haven't found any other solution so far and will proceed with your suggestion of pre/post jobs.
In the tests this option did the work really good and easy.
Unfortunately the jobs are run at the very beginning and the end of the job.
VMs will be unlimited for the whole copy job and only need to be while the snapshot removal.
Would be more smooth if the pre/post jobs could be more granular assigned to the job states pre and post the snapshot creation / removal.
I think another idea would be a Orchestrator workflow with some triggerpoints, but this would be a feature in the future and so far a bit erroneous perhaps.
Regards
TBL
-
- Product Manager
- Posts: 6551
- Liked: 765 times
- Joined: May 19, 2015 1:46 pm
- Contact:
Re: VM IO Limits and deleting Backupsnapshots
I think we already have something like that - pre-freeze/post-thaw scripts are run before VMware snapshot creation and after snapshot deletion, respectively. The scripts can be specified on a per-VM basis in the Guest Processing menu.Would be more smooth if the pre/post jobs could be more granular assigned to the job states pre and post the snapshot creation / removal.
Thanks!
-
- Service Provider
- Posts: 4
- Liked: 1 time
- Joined: Mar 05, 2019 4:54 pm
- Full Name: Tobias Blum
- Contact:
Re: VM IO Limits and deleting Backupsnapshots
Dear PTide,
thank you again for your reply.
We've checked pre-freeze/post-thaw scripts and find them not useful, because they run in the VMs and cannot perform tasks to the vCenter.
Even there is a new issue, that vms with snapshot cannot be modified on Storage Policy or IOPs.
BUT!
vMotion and Snapshot (Removal) are not charged to VM IOs anymore in SIOC v2.
If you configure IO Limits directly in VM Edit per VMDK disk you can see even the Snapshot removal is total slow.
If you configure IO Limits with Storage Policies, then you can do vmotions and snapshots as fast as possible, even if the IOP limit is set to 10.
So the issue is never been an issue. SIOC v1 (directly on VMDK) vs. SIOC v2 (per Policy) are completely different Features.
I would highly recommend to only use Storage Policy for IO Limits for everybody, who does vmotions or snapshots on backups.
Some cases surely will be better solved with SIOC v1
Regards
TBL
thank you again for your reply.
We've checked pre-freeze/post-thaw scripts and find them not useful, because they run in the VMs and cannot perform tasks to the vCenter.
Even there is a new issue, that vms with snapshot cannot be modified on Storage Policy or IOPs.
BUT!
vMotion and Snapshot (Removal) are not charged to VM IOs anymore in SIOC v2.
If you configure IO Limits directly in VM Edit per VMDK disk you can see even the Snapshot removal is total slow.
If you configure IO Limits with Storage Policies, then you can do vmotions and snapshots as fast as possible, even if the IOP limit is set to 10.
So the issue is never been an issue. SIOC v1 (directly on VMDK) vs. SIOC v2 (per Policy) are completely different Features.
I would highly recommend to only use Storage Policy for IO Limits for everybody, who does vmotions or snapshots on backups.
Some cases surely will be better solved with SIOC v1
Regards
TBL
Who is online
Users browsing this forum: Bing [Bot] and 14 guests