Gents, got a message back from IBM regarding the 6.2.3 client.
Here's the doc they pointed me to:
"It looks like the issue might be related to not keeping the TSM metadata
(control files) on disk while allowing the actual virtual machine backup data
to reside on tape, as documented under the "Tape configuration guidelines
Backup to tape" heading in the following DCF:
'Tivoli Storage Manager for Virtual Environments - Data Protection for VMware
Tape Support Statement':
http://www-01.ibm.com/support/docview.wss?uid=swg27021081
"
According to the "Tape Config" section referred to, you have to setup a Disk
pool that DOES NOT migrate to onsite tape. (of course you should backup to
tape for offsite, but you'll need to restore the disk pool at DR time). Then
setup a special Management Class that points the data to that disk pool, and
add an entry to the dsm.opt file like so:
VMCTLMC "VMDKCTLBACKUP_MC"
(or whatever you call your "MC").
I still can't restore directly to the SAN volume for some reason, but the
restores are MUCH faster. (16MB/s over a GB connection, and I don't need the
NBD setting explicitly any longer it fails back to that automatically as it
should). NOTE: this is only needed with the 6.2.3 client, and newer I would
assume.
See Ya'
Howard Coles Jr., RHCE, CNE, CDE
John 3:16!
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andreas Kaiser
Sent: Friday, April 15, 2011 2:48 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] AW: VStore Restore vmdk
Same here. Performance was fine with client 6.2.2 (50 MB/s range) but restore
performance dropped dramatically with 6.2.3 (2-3 MB/s range, decreasing with
increasing disk size). It does not depend on the kind of datastore or access
path as I tested both local ESX disks via LAN and different kinds of directly
mapped SAN datastores. But I noticed that in 6.2.2, the backup files on the
tape had full disk size whereas 6.2.3 uses 128MB chunks, likely to support
incremental backups in the TDP product using change block tracking.
Monitoring the network data rate TSM to agent showed that the 128MB chunks are
transferred at high speed, spaced apart by idle delays initially starting in
the several minute range shrinking to 10 seconds near the end of each restored
disk. To me it looks a bit like tape movement between each of those chunks. The
same 128MB chunks are also noticable at backup time, although without those
horrible gaps. Data was streaming in 6.2.2.
There is a case open at IBM, otherwise I'd try downgrading to 6.2.2.
Gruss, Andreas
-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag
von Howard Coles
Gesendet: Donnerstag, 14. April 2011 16:04
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: [ADSM-L] VStore Restore vmdk
I have a vmdk backup server setup using LAN free backups, and the vstore
API. I have been able to backup a couple of vmdk files (full backup),
and that appeared to work pretty well.
However, when I try to restore the guest node I get very horrible
performance. The initial restore appears to work, and the vm guest gets
created and the snapshot setup for restore. But, when the actual data
transfer starts it will move about 35 to 60 MB at a time and then sit
and wait for long periods (average aggregate rate is 220 KB/s). I have
a call open with IBM but they haven't been able to come back with
anything (completely devoid of response the last day or so) to resolve
the issue.
> Der neue SÜDKURIER. Weil Zukunft Tradition hat.
> Jetzt am Kiosk, im Internet und auf dem iPhone.
> Mehr Infos: http://www.suedkurier.de/relaunch
Die Auftragsabwicklung erfolgt auf Grundlage der jeweils gültigen AGB der
beauftragten Unternehmen im SÜDKURIER Medienhaus (http://www.suedkurier.de/agb
).
|
