MSA2040 + D2700 Enclosure - Server 2012R2 Hyper-V Cluster

[IngentisGmbH]

Hi,

I have a two-node Server 2012 R2 Hyper-V Cluster running on HP DL380p Gen8 and MSA 2040 (FibreChannel)+D2700 Enclosure.

I have several Disks configured (2x Raid6, 4 Raid1) and I added the Raid6-Volumes (on MSA2040) to/as CSV - but when I try to add one of the Raid1Volumes (on D2700) as CSV I get an error:

Error Code: 0x08007139f

The Group or resource is not in the correct state to perform the requested Operation.

EventLog (Source FailoverClustering; ID:5144):

While adding the disk ('Volume3') to Cluster Shared Volumes, setting explicit snapshot diff area association for volume ('\\?\Volume{811afdcd-2ebd-4475-8e78-a86d9ab991fe}\') failed with error 'HrError(0x8007139f)'. The only supported software snapshot diff area association for Cluster Shared Volumes is to self.

Is there a support-Issue for Server 2012 R2 and D2700 enclosure?

Regards

Christian

[Torsten.]

The D2700 is connected to the MSA2040, right?

So the difference must be in the vdisk/volumes settings (I assume you created a visk only for some disks in the D2700) - so compare the vdisk and volumes settings.

[IngentisGmbH]

Thanks for your reply.

Yes - the MSA2040 is connected via FC to the FC-switches - Server 2012 R2 MPIO is configured correctly

The D2700 is connected to the MSA2040 via SAS.

all v-disks are configured with the same settings. (see Attachments)

[Torsten.]

If you do

# show volumes

from the MSA Cli, do you see "snap pool" or something different from "standard" in CLASS?

[IngentisGmbH]

Hi,

no - there is Class = standard for every vdisk:

################################################################################

# show volumes
Vdisk          Name            Size     Serial Number
  WR Policy     Cache Opt        Read Ahead Size  Type         Class
  Qualifier                      Volume Description
  WWN                               Health     Health Reason
  Health Recommendation
--------------------------------------------------------------------------
vD5_R1_900_01  Volume0_Quroum  1023.4MB 00c0ff1a1e4d00002d9d905201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1E4D2D9D905201000000  OK

vD1_R6_300_01  Volume1         2696.5GB 00c0ff1a1e4d000070838e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1E4D70838E5201000000  OK

vD2_R6_300_02  Volume2         2696.5GB 00c0ff1a12830000c7838e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1283C7838E5201000000  OK

vD3_R1_146_01  Volume3         146.0GB  00c0ff1a1e4d00001e848e5201000000
  write-back    standard         Adap  N/A                                      
  600C0FF0001A1E4D1E848E5201000000  OK

vD4_R1_146_02  Volume4         146.0GB  00c0ff1a128300007f848e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A12837F848E5201000000  OK

vD5_R1_900_01  Volume5         897.6GB  00c0ff1a1e4d0000709d905201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1E4D709D905201000000  OK

vD6_R1_900_02  Volume6         898.6GB  00c0ff1a128300001a858e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A12831A858E5201000000  OK

vD7_R1_900_03  Volume7         898.6GB  00c0ff1a1e4d000057858e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1E4D57858E5201000000  OK
                                     --------------------------------------------------------------------------
Success: Command completed successfully. (2013-11-26 12:06:00)
################################################################################

[Torsten.]

But it looks different for volume3:

vD2_R6_300_02  Volume2         2696.5GB 00c0ff1a12830000c7838e5201000000
  write-back    standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1283C7838E5201000000  OK

vD3_R1_146_01  Volume3         146.0GB  00c0ff1a1e4d00001e848e5201000000
  write-back    standard         Adap  N/A                                      
  600C0FF0001A1E4D1E848E5201000000  OK

[IngentisGmbH]

ups :)
you are right - sorry - and how can I change/fix that?

[Torsten.]

Looks like the "Type" is "N/A" - this is the problem.

Could you again do

show volumes Volume3

to ensure there is no problem with cut and paste?

I don't think there is a way to change this from "N/A" to standard other then re-creating the volume.

[IngentisGmbH]

# show volumes Volume3
Vdisk          Name     Size    Serial Number                     WR Policy
  Cache Opt        Read Ahead Size  Type         Class
  Qualifier                      Volume Description
  WWN                               Health     Health Reason
  Health Recommendation
-------------------------------------------------------------------------------
vD3_R1_146_01  Volume3  146.0GB 00c0ff1a1e4d00001e848e5201000000  write-back
  standard         Adaptive         standard     standard
  N/A
  600C0FF0001A1E4D1E848E5201000000  OK

-------------------------------------------------------------------------------
Success: Command completed successfully. (2013-11-26 12:36:23)

I saw, there is no ChunkSize defined for the vDisks which are having problems.

Is it best practise to set the chunkSize for vdisks to 512k for Hyper-V Cluster?

[Torsten.]

I'm not sure now to which column the "N/A" belongs...

However, if the chunk size is not modified during vdisk creation, it is default at 512.

Do

show vdisks vD3_R1_146_01

I would just delete the volume and the vdisk and start over, creating this vdisk again, then create the volume again.
There is something wrong with it.