npiv fileserver question

[Raist]

Hello,

I'm thinking that someone out there may have done this and have some advice for me.

I want to migrate our primary file server to a virtual machine but would like to use NPIV due to the extensive downtime a migration would cause. So OS in on one disk and the file storage is on our san (IBM ESS800). I want to migrate the OS drive and use NPIV to connect the storage to the newly imported server. While testing I'm running into trouble, server 2003 is reporting a disk but I either get a disk unreadable error or event viewer throws disk not ready / driver reported an error. I followed some brocade instructions for how to setup npiv; high level is virtual machine is off, enable npiv and create WWN, add the raw disk (tried this with scsi 0:x and scsi 1:x thinking a separate controler may help) in virtual mode, add the wwn at the brocade switch (ports have npiv enabled) and the SAN then power on the windows server.

All help is greatly appreciated and thank you all for taking the time to read this over.

[Raist]

So here is a quick update. I've updated the qlogic card firmware and swapped to using wwpn's in the fabric. No virtual port is bing created based on /proc/scsi/qaXXX/4,5,6,7 in the vmkernel log I'm receiving Peripheral qualifier 0x1 not supported. Since the virtual port isn't created because the san address is invalid I'm not sure where to start looking. Any ideas?

[a_p_]

In the current implementation of NPIV, it is - VMware forgive me - useless (except for documentation).

What you need to do to attach the LUN as a RAW device, is to present the LUN to your ESX hosts using the same LUN-ID and attach the LUN to the VM as a RAW device mapping. I usually use SCSI-ID 1:0 and up for RDM's.

André

[Raist]

So I need to use the same LUN ID on the virtual machine as I'm using with the ESX servers? I followed to the T and no love. I've also tried removing the wwn's from the fabric to see if that was the issue.

I don't want to sound like I'm just guessing but at this point I really am guessing because I've tried everything I can think of.

[a_p_]

I would attach the LUN as a RAW device to your VM without configuring NPIV (you don't need it)

So what you should do - if not already done - is:

1. Setup zoning - I recommend single initiator zoning --> 1 zone = 1 HBA/initiator port + all storage/target ports

2. Create the HOSTs or HOST groups on your storage and present the LUN to the ESX hosts using the same LUN-ID for all ESX hosts

3. Rescan the HBA's on your ESX hosts (you should see the LUN in the "Storage Adapter" view now

4. Attach the LUN as a second HDD to your VM as a RAW device map using SCSI 1:0

André

[Raist]

Ok I figured it out... Lovely old IBM storage cannot format on a per LUN basis it must be formatted on a per 8-pack basis and there was a sun system attached to that specific lun in the past, in which the ESX server cannot format due to a lock in the file system.

I do understand what you are saying for raw mapping but for the file server migration I will need to display the same LUN ID to the imported server to aviod setting up all of the share permissions. That part I can figure out, now on to the WWN's, should I use multiple WWN's? Currently I planed to mimic what the physical hardware which is with 2 WWNN and 4 WWPN's but then I believe I should install (assumption) the multipathing driver for windows but logic (at least my logic) would assume that since all HBA's support NPIV and the virtual machine WWN's are configured across all fabrics with all esx servers accessing the LUN correctly there would only be the need for 1 WWN.

Thoughts?

[a_p_]

Again, NPIV is just for management. There is no benefit for you and it does not provide an additional view to the SAN LUN.

Please read "N_Port ID Virtualization" in the White Paper - Providing LUN Security

from the White Paper:

With NPIV, SAN administrators see the virtual machines and can identify their traffic and add a redundant layer of LUN masking and quality-of-service controls, but the virtual machines still are isolated as before and do not have any additional visibility into the SAN. They still do not see Fibre Channel HBAs and cannot see the Fibre Channel targets or scan for LUNs that are not explicitly assigned to them by the ESX Server administrator.

André

[Raist]

Thank you, that doc is exactly what I was looking for.