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@VM.MARIST.EDU] On Behalf Of Andreas Kaiser Sent: Friday, April 15, 2011 2:48 AM To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] Im Auftrag von Howard Coles Gesendet: Donnerstag, 14. April 2011 16:04 An: ADSM-L@VM.MARIST.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 ).
