Hi Skylar,
I'm confused by your question. You say you are doing migration from the
target to the source. But that doesn't make sense. In server-to-server
virtual volumes, data is sent from the source to the target. Your
configuration shows that you have a storage pool called ONSITE-MALI on the
I'm testing out virtual volumes at our site, and I'm trying to figure
out how to get virtual volumes deleted from the target server. When I do
migration on the source server from the target server, the occupancy on
the source server goes down but the target server stays the same. I'm
using a DISK
yep, I did consider these things, but I double checked:
- 100/Full
- The files were compressed when they were backed up, The client is not
being taxed decompressing the data stream at all (currently 89% idle)
- we started with one thread, but are up to 4 now. Each one is performing
pretty pathetic
Shawn,
Based on this information it appears that the VTL is only attached to
the TSM server correct? So, the data to the client is not going to be as
fast as restoring to the TSM server. Things to consider are...
What is the LAN speed and duplex settings for the client?
How is the LAN traffic when
5.4.1 AIX Server
5.3.4 AIX 5.1 Client
Performing a 12 gB restore. (6x2gB files)
The restore is performing at a rate of about 250-500 KB/s with bursts up
to a whopping 750KB/s (Looking at the VTL drive monitor)
If we perform the restore locally to the TSM server's file system, it is
fast. (20-3
Thanks for the answer Skylar!
Offset, alligment or diskcrossing problem is an Intel architecture
problem hitting both Linux and Windows. In Windows you can use diskpar
or diskpart to overcome it. EMC have an white paper "Aligning GPT Basic
and Dynamic Disks For Microsoft Windows 2003".
However,
