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.
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.
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!
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
4 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!