I am restoring a VM with 3 hard drives. The restore task shows it has assigned a proxy to all 3 drives. The first drive is restoring, it took about 10 minutes before the second one started but it is just sitting there after showing restore started with hotadd. I have noticed this in the past as well. It won't start restoring data to a second (or more) volume until the first one is completed. Is there a reason for why it won't do them in parallel?
Edit : The 1st drive was 700GB, drives 2 and 3 are 100GB. Once drive 1 finished, it started restoring drives 2 and 3 in parallel. Why would it have done all 3 at once if there was sufficient capacity on the proxies?
Thanks
-
- Expert
- Posts: 116
- Liked: 31 times
- Joined: Mar 16, 2023 5:47 pm
- Contact:
-
- Chief Product Officer
- Posts: 32237
- Liked: 7598 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Why do restores with multiple VMDK not run in parallel?
If there was sufficient capacity of task slots in all infrastructure components, then it would have been restoring all three at once indeed. But perhaps something was missing.
-
- Expert
- Posts: 138
- Liked: 23 times
- Joined: Mar 18, 2021 6:04 pm
- Contact:
Re: Why do restores with multiple VMDK not run in parallel?
Hello,
It should definitely restore in parallel by default if enough resources are available. One "annoying" thing about this btw, is that the ETA calculation of the job is very basic, it just takes the current cumulated restore speed and divides the remaining GBs to restore, but of course when there are several disks of different sizes, once it's restoring less and less disks in parallel, the global restore speed decreases and the ETA increases so it's not relevant and you don't know the "real" ETA until it's only restoring the last disk. It should be at least a little smarter to take this into account and be able to calculate a <relatively> accurate ETA based on the size and numbers of vmdk's to restore and averaging assumptions.
It should definitely restore in parallel by default if enough resources are available. One "annoying" thing about this btw, is that the ETA calculation of the job is very basic, it just takes the current cumulated restore speed and divides the remaining GBs to restore, but of course when there are several disks of different sizes, once it's restoring less and less disks in parallel, the global restore speed decreases and the ETA increases so it's not relevant and you don't know the "real" ETA until it's only restoring the last disk. It should be at least a little smarter to take this into account and be able to calculate a <relatively> accurate ETA based on the size and numbers of vmdk's to restore and averaging assumptions.
-
- Expert
- Posts: 116
- Liked: 31 times
- Joined: Mar 16, 2023 5:47 pm
- Contact:
Re: Why do restores with multiple VMDK not run in parallel?
There were no backups or other restores running at the time. The proxies can each handle 8 parallel tasks, so I am still curious why it would not run them in parallel. Is this something support can help me figure out? I am happy to open a SR for this
-
- Chief Product Officer
- Posts: 32237
- Liked: 7598 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Why do restores with multiple VMDK not run in parallel?
Yes, of course they can see it from the debug logs.
Who is online
Users browsing this forum: No registered users and 72 guests