BE 11d and Quantum SuperLoader 3 under VMware ESX server - no idle devices

[InforMed_Direct]

Here's the set-up:

• Dell PowerEdge 2950

• Windows 2003 Server R2 64 bit

• Quantum SuperLoader 3 robotic library

• Adaptec AHA-29320 SCSI adapter (PCI-Express)

• Backup Exec 11d

When Windows 2003 server and BE is installed on the raw hardware, it works fine.

We're evaluating VMware ESX server and virtualisation as part of our disaster recovery plan and server consolidation. I have built an evaluation of ESX server v3.5. It recognises the SCSI card which is the first hurdle. I'm able to add in two SCSI devices into the virtual server and when BE is installed, it recognises the tape drive although the medium changer says "Unknown medium changer". Then again, it shows it like that on the raw install.

However, when I try and inventory the slots (it shows the 8 slots), the job stays in the queue saying "Ready; No idle devices are available".

One thing I did notice that's different between the raw hardware install and the virtual environment is how the devices are listed. Under the raw hardware;

SERVER017

Robotic libraries

QUANTUM 1

Tape drive

QUANTUM 2

Slots

But on the virtual sever, it's different:

VSERVER017:

Stand-alone drives

QUANTUM 1

Robotic Libraries

QUANTUM 2

Slots

This suggests to me that BE isn't realising the tape drive and slots are the same unit, maybe...

I realise this is a really off the wall request but we can't be the first to want to run BE in a virtual environment. I've asked on the BE/Symantec forum as well but I suspect this is more of a ESX server issue than BE as such.

Cheers, Rob.

[dconvery]

WOW!! I'm surprised you got THAT far. This is an unsupported configuration. ESX doesn't really virtualize tape devices. You can use the device through the service console to do local backups, but that is not recommended. You could add a SAN router and NPIV, but that only has experimental support right now.

[InforMed_Direct]

I don't think it's virtualising the tape device as such - it's virtualising the Adaptec SCSI card that happens to have the tape drive and robotic library attached.

I thought that virtualisation of SCSI devices like this was supported?

Cheers, Rob.

[InforMed_Direct]

I think SCSI tape drives are supported as there are several KB articles about setting it up. In addition, Backup Exec 11d is a supported package within a VM as described here:

I suspect that robotic tape drives is causing the problem.

Cheers, Rob.

[dconvery]

...And now I know. I guess the big thind is that the library is capable of multi-target. Many only give you multi LUN. Is the changer "seen" as it's own SCSI ID?

VMware supports attaching SCSI drives to the ESX Server using Adaptec SCSI adapters. Using other adapters, such as LSI MPT‐Fusion SCSI, is not

supported.

If you are using a tape drive library (versus using a stand‐alone tape drive), the library must be multi‐target, and not multi‐LUN.

Set the tape drive’s virtual target ID in the virtual machine’s configuration to be the same as the physical target ID.

[InforMed_Direct]

...And now I know. I guess the big thind is that the library is capable of multi-target. Many only give you multi LUN. Is the changer "seen" as it's own SCSI ID?

VMware supports attaching SCSI drives to the ESX Server using Adaptec SCSI adapters. Using other adapters, such as LSI MPT‐Fusion SCSI, is not

supported.

If you are using a tape drive library (versus using a stand‐alone tape drive), the library must be multi‐target, and not multi‐LUN.

Set the tape drive’s virtual target ID in the virtual machine’s configuration to be the same as the physical target ID.

Well it's using an Adaptec so that's a tick there.

I haven't a clue whether the library is multi-target or multi-LUN as my knowledge of SCSI is scant.

But the last one I can have a go at...

Cheers, Rob.

[InforMed_Direct]

One thing that is a bit weird is that I'm sure when the server boots up it only shows one device in the SCSI BIOS but there's two devices available in ESX Server (Media and Tape).

Cheers, Rob.

[InforMed_Direct]

Here is a screenshot of how the library appears in ESX Server:

Cheers, Rob

PS. Click on image to enlarge.

[dconvery]

You are in LUN mode. Your tape device is SCSI Target 5, LUN 0 and the changer is SCSI Target 5, LUN1. That is why it is not working. I just looked at the user guide and it doesn't look like it can be changed to target mode. What you may want to try is changing it to sequential mode. This will make the changer invisible to the host/guest, and make it look like one big tape. This kinda defeats the ability to send tapes offsite, rotate, etc.

[InforMed_Direct]

I wonder if those articles about multi-target versis multi-LUN are to do with using the library under ESX server (i.e. Linux) itself. But then again, maybe not.

I've just turned on multi-LUN in the Adaptec BIOS and yes, you are correct - target 5 LUN 0 is the tape drive and target 5 LUN 1 is the tape library. I wonder if the Quantum SuperLoader 3 can be reconfigured to use a multi-target?

I think I'm beginning to understand what's happening. I assume on base hardware installation, the Backup Exec drivers see the single target with multiple LUN and this allows it to sort it out. But when it's virtualised with ESX Server, it's passing in two separate SCSI targets which is confusing Backup Exec.

Cheers, Rob.

[dconvery]

I think it is more to do with the way VMware virtualizes the SCSI. You can use the autoloader with linux just fine. You can check with Quantum, but it looks like the SuperLoader only does multi-LUN. You may have to get a FC router or use VCB and a pysical server. I hear that VCB 1.1 and VC2.5 can run on the same machine now..

[dmorgan]

Not sure if this matters or not, but I don't think that VCB works under 64-bit windows. I used a physical machine running Server 2003 R2 64-bit, running Arcserve, to connect to our IBM Fibre tape library. That all worked fine. VCB would not. Moved entire setup to 32-bit windows, VCB works flawlessly. So, if you are planning on using VCB to back up any VM type environments, you may wish to switch to 32-bit windows.

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[InforMed_Direct]

Yes, I think you are correct. It's the way that the Adaptec SCSI adapter is virtualised as the LSI Logic SCSI adapter. It doesn't appear to virtualise the LUN system seamlessly in that it doesn't preserve the physical target/logical unit system through to the virtual server.

This means that Backup Exec sees the tape library and tape drive as two separate SCSI devices and therefore cannot control them together. Well that's my theory anyway.

So the wish here to VMware is to virtualise the logical unit system if possible...we're going to have to try and find a non-virtualised server on which to run Backup Exec which is a shame.

Cheers, Rob.

[InforMed_Direct]

A result!! Courtesy of Symantec. There is a feature in Backup Exec (device wizard) whereby you can tell it which drive is associated with the robotic library. Working a treat now.

Thinking about it, what ESX server had actually done was change a logical unit into a physical target. Just needed that bit of knowledge with BE about how physical target devices can be configured to work.

Cheers, Rob.

[InforMed_Direct]

Okay, it's been a while since I posted this thread and the answer to whether you can use a Quantum Superloader 3A with Backup Exec 12d running on 64 bit Windows 2003 Server hosted on ESX Server 3.5 is maybe

It works but it's been very unreliable esp. on large jobs that tend to span tapes. The job would often fail leaving the tape with the deaded "end marker unreadable" status. Sometimes it will work for a few weeks and then bang. The ESX console does show errors in the log and my suspicion is that the virtualisation of the SCSI adapter isn't perfect and maybe the 64 bit OS doesn't help.

We've just build a 32 bit bare metal Windows 2003 server and connected the Superloader 3a to that. It's just finished a 4TB backup over many tapes without a hitch. We failed to get this backup to run on the original set-up three times. I'm going to run it again several times to make sure it's not a fluke.

So in summary "not recommended"

Cheers, Rob.