Unsolved
This post is more than 5 years old
40 Posts
0
5594
September 7th, 2010 15:00
Very slow virtual disk copy..need some help
Got done hooking up our MD1000 to our MD3000i. Created a couple new disk groups on the MD1000, 5 disks each. The disk groups are RAID 0 since they will be used for virtual disk copies only. Two virtual disks per group. Doing my first virtual disk copy, of a snapshotted virtual disk that is on the MD3000i. Only thing running on the virtual disk are 3 VMs that are doing nothing. Just test VMs I'm using. Total size of data being copied is 60GB. Set at medium priority the MD3000i told me 26 hours to copy. Set at highest it says 1 hour 30 minutes. Something is wrong. At 3Gbps (SAS speed) this should copy within a few minutes. I also see very high latency (over 100ms) on the MD3000i right now with this copy running at highest priority. Even the virtual disks in different disk groups. Guessing due to the controller not able to handle this.
What's going on? Cache seems enabled and working fine on the controllers. I have dual Dell SAS cables between the MD3000i and MD1000.
grendels_Arm1
40 Posts
0
September 7th, 2010 16:00
OK lemme ask this. When you do a virtual disk copy does it copy the complete virtual disk or only the data on that disk? Meaning if you have a 660GB virtual disk but only 60GB is used is it copying 660GB or 60GB? I'm guessing 660GB as the SAN doesn't know anything about used data. If this is the case it sure does make virtual disk copies alot slower than I had hoped. Also I'm glad I didn't create mega huge virtual disks. I had a feeling huge virtual disks would be bad for virtual disk copies. Need to confirm with Dell.
Also if this is the case would it be better to copy all 4 virtual disks (660GB each) at one time or do them one at a time? The documentation does state you can have 8 active copies at one time so that implies you might want to do more than one at a time.
Dev Mgr
6 Operator
•
9.3K Posts
0
September 8th, 2010 07:00
The SAN indeed doesn't know about "data"; when it does a virtual disk copy, it has to copy the whole 660GB in your case.
As the production virtual disk goes into a read-only mode for the duration of the copy process, you effectively lose access to the disk (most OSes won't like it if they suddenly, for no apparent reason, can no longer write to the disk).
One trick is to do a snapshot of the virtual disk, and then diskcopy the snapshot. This takes some more space, but is a bit more user friendly.
grendels_Arm1
40 Posts
0
September 8th, 2010 09:00
We're doing exactly what you mention by recreating a snapshot first, then starting the virtual disk copy, then we'll have to figure out a good time to disable the snapshot. If you run it at the command prompt the SMcli command completes within a minute but the virtual disk copy is going on. This means if I create a batch job that does these three things all in a row it won't work as the snapshot will disable while the vdd is still going. I'm going to have to just let the snapshot stay enabled and disable it the next day or something.
Amazing that 660GB at medium priority it says would take 26 hours!