Some time ago, I posted a blog entry titled Carry a Jukebox with you, if you’re using Linux, which referred to using linuxvtl with NetWorker. The linuxvtl project is run by my friend Mark Harvey, who has been working with enterprise backup products as long as me.
At the time I blogged, the key problem with the LinuxVTL implementation was that NetWorker didn’t recognise the alternate device IDs generated by the code – it relied on WWNN’s, which were the same for each device.
I was over the moon when I received an email from Mark a short while ago saying he’s now got multiple devices working in a way that is compatible with NetWorker. This is a huge step forward for Linux VTL.
So, what’s changed?
While I’ve not had confirmation from Mark, I’m working on the basis that you do need the latest source code (mhvtl-2009-11-10.tgz as of the time of writing).
The next step, to quote Mark, is that we need to step away from StorageTek and define the library as SpectraLogic:
p.s. The “fix” is to define the robot as a Spectralogic NOT an L700.
The STK L700 does not follow the SMC standards too well. It looks like
NetWorker uses the ‘L700’ version and not the standards.
The Spectralogic follows the SMC standards (or at least their
interruption is the same as mine 🙂 )
The final part is to update the configuration files to include details that allow the VTL code to generate unique WWNNs for NetWorker’s use.
Starting out with just 2 devices, here’s what my inquire output now looks like:
[root@tara ~]# inquire -l -l flag found: searching all LUNs, which may take over 10 minutes per adapter for some fibre channel adapters. Please be patient. scsidev@0.0.0:SPECTRA PYTHON 5500|Autochanger (Jukebox), /dev/sg2 S/N: XYZZY ATNN=SPECTRA PYTHON XYZZY WWNN=11223344ABCDEF00 scsidev@0.1.0:QUANTUM SDLT600 5500|Tape, /dev/nst0 S/N: ZF7584364 ATNN=QUANTUM SDLT600 ZF7584364 WWNN=11223344ABCDEF01 scsidev@0.2.0:QUANTUM SDLT600 5500|Tape, /dev/nst1 S/N: ZF7584366 ATNN=QUANTUM SDLT600 ZF7584366 WWNN=11223344ABCDEF02
Finally, here’s what my /etc/mhvtl/device.conf and /etc/mhvtl/library_contents files now look like:
[root@tara mhvtl]# cat device.conf VERSION: 2 # VPD page format: # <page #> <Length> <x> <x+1>... <x+n> # NOTE: The order of records is IMPORTANT... # The 'Unit serial number:' should be last (except for VPD data) # i.e. # Order is : Vendor ID, Product ID, Product Rev and serial number finally # Zero, one or more VPD entries. # # Each 'record' is sperated by one (or more) blank lines. # Each 'record' starts at column 1 Library: 0 CHANNEL: 0 TARGET: 0 LUN: 0 Vendor identification: SPECTRA Product identification: PYTHON Product revision level: 5500 Unit serial number: XYZZY NAA: 11:22:33:44:ab:cd:ef:00 Drive: 1 CHANNEL: 0 TARGET: 1 LUN: 0 Vendor identification: QUANTUM Product identification: SDLT600 Product revision level: 5500 Max density: 0x46 NAA: 11:22:33:44:ab:cd:ef:01 Unit serial number: ZF7584364 VPD: b0 04 00 02 01 00 Drive: 2 CHANNEL: 0 TARGET: 2 LUN: 0 Vendor identification: QUANTUM Product identification: SDLT600 Product revision level: 5500 Max density: 0x46 NAA: 11:22:33:44:ab:cd:ef:02 Unit serial number: ZF7584366 VPD: b0 04 00 02 01 00
NOTE in the “device.conf” file the NAA entries – these are key!
With these changes done, jbconfig worked without missing a beat, and suddenly I had a 2 drive VTL running.
Great going, Mark!
While I’ve not yet tested, I suspect this fix will also ensure that the VTL can be configured on multiple storage nodes, which will be a fantastic improvement for library support work as well.
[Edit, 2009-11-18]
I’m pleased to say that the changes that have been made allow for the VTL to be created on more than one storage node. This presents excellent opportunities for debugging, testing and training:
Is it possible to use this kind of technology in productive environments? (Many Gigabyte of data)
Is it safe, what would you think?
While I have the greatest respect for the developer, I can’t say I’d recommend LinuxVTL for use in a production environment. That’s not because I distrust it – so far it’s been remarkably stable. However, there’s no commercial support for LinuxVTL, and I think having appropriate support levels is very important in a backup environment.
What’s more, LinuxVTL is kernel-dependent, meaning that you would also have to recompile etc., every time you update your kernel.
There’s nothing stopping you using it in a production environment, to be sure, but my recommendation for use of LinuxVTL has always been as part of testing and evaluation environments, not production. (That’s not to say it won’t get there, of course.)
At the moment, I would not use the vtl for production use.
The ‘back-end’ storage format is implemented as a simple on disk double-linked-list.
I make NO guarantees to keep tape format consistent between releases. Although it has only changed about 3 times in total of 4years.
The backend storage is being reworked to provide a more efficient (performance wise) format.
One of the problems seen (when specifying larger media sizes) include SCSI timeouts during seeking (space).
Also, the current linear ‘walk-double-linked-list’ does have a negative impact on the page cache.
I have written a complete step by step howto for MHVTL virtual tape library with Networker server 7.6 on OpenSUSE 11.2 (in a Virtualbox VM). Maybe someone find this useful: http://otmanix.de/english/2010/08/18/networker-and-mhvtl-in-a-virtualbox-vm-part1/
Kind regards, Otmanix