Hopefully, this does not post several time...if it does apologies in advance. (My email address changed.)
Assuming you have the TS1130's in a 3584: you can create virtual libraries and assign slots and drives to each library. We did this to avoid having a single point of failure in the TSM library manager and also not have any contention for resources on the library, except the accessor. However, the "shared" accessor has not been an issue for approximately 500 mounts per day. Doing this keeps everything nice and neat for your TSM servers. Just my 2 cents worth. BTW, I am curious: how much are you backing up nightly? What is the configuration of the library? Regards, Mahesh ________________________________________ From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Harry Redl [harry_r...@yahoo.com] Sent: Thursday, January 07, 2010 18:54 To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] VMWare and TS1130 tape drives Hi, this can work (I admit I haven't tried it with TS1130) - ESX4.0 supports FC tape drives (new feature - was not working with 3.5) and you can dedicate whole FC HBA to the virtual machine. But even if it works it remains unsupported. Harry ________________________________ From: Remco Post <r.p...@plcs.nl> To: ADSM-L@VM.MARIST.EDU Sent: Thu, January 7, 2010 11:24:50 PM Subject: Re: [ADSM-L] VMWare and TS1130 tape drives On 7 jan 2010, at 22:21, Zoltan Forray/AC/VCU wrote: > We are doing some serious looking at our "dr" (or BC) plans. > > One thought for an offsite TSM server would be as a VMWare guest and/or > multiple guests. > > Since an absolute requirement would be a TS1130 tape drive (to restore the > DB), the question came up about whether you could virtualize the > TS1130/drivers so a Linux guest VM could access these drives. > I believe that the ts1130 is fc only, no scsi or sas, vmware doesn't support access to fc drives from a guest, last time I heard. So there it stops. If you'd have scsi or sas tape devices, you could get them to work from within a vmware guest, no problem. Support might be an issue, if I read the docs right. > If this is doable, has anyone done such a configuration, that actually > works? What did it take? > > How about multiple TSM servers on one box (VM or real hardware)? How > would they share the tape drives - only through library sharing as we do > now? What if I had to cram 5-TSM servers on one VMWare (or hardware) > guest, since our current configuration splits our 3494 library between > 2-TSM library manager servers? > > Another thought was to have a "warm" VMWare TSM server running offsite and > doing DB backups via server-to-server storage pools but was considering > how much work it would be to rebuild another VMWare TSM server from the DB > backups on this VMWare TSM server? > > Looking for any input/feedback on folks who have gone down this path, > either successfully or not! If I have to go back to management to say > "gotta have a physical server and tape drives to even think about > recovering/rebuilding a TSM server offsite", I need to justify/back it. > Zoltan Forray > TSM Software & Hardware Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622 Notice: The information and attachment(s) contained in this communication are intended for the addressee only, and may be confidential and/or legally privileged. If you have received this communication in error, please contact the sender immediately, and delete this communication from any computer or network system. Any interception, review, printing, copying, re-transmission, dissemination, or other use of, or taking of any action upon this information by persons or entities other than the intended recipient is strictly prohibited by law and may subject them to criminal or civil liability. Carilion Clinic shall not be liable for the improper and/or incomplete transmission of the information contained in this communication or for any delay in its receipt.
