VMware Cloud Community
ian_fretwell
Contributor
Contributor

Upgrade VMFS from 3.21 to 3.31

Hi,

Can anybody please shed some light on the differences between the VMFS 3.21 in v3.0.2 and the VMFS 3.31 used by 3.5 ? I haven't seen this change mentioned anywhere and only spotted it because I had to create a new datastore - is it possible to in-place upgrade from to the other for example (strange that the upgrade to 3.5 didn't do this though...)

Thanks,

Ian.

Reply
0 Kudos
21 Replies
depping
Leadership
Leadership

Noticed the same thing a couple fo days ago, I and am also looking for a way to upgrade it.

Duncan

My virtualisation blog:

Reply
0 Kudos
J-D
Enthusiast
Enthusiast

Hi,

I was wondering if you have an ESX Cluster with 3 ESX Servers and a shared SAN storage running vmfs 3.21 and you upgrade one ESX server. Will this affect vmfs access for the other ESX's?

Apparently the upgrade of one ESX to 3.5 won't upgrade vmfs but I just want to be sure...

TIA.

Reply
0 Kudos
gdesmo
Enthusiast
Enthusiast

I am adding/re-installing 3.5 hosts to an existing 3.0.2 farm. So I am assuming all my lun's will remain at vmfs 3.21.

Problems with this?

Reply
0 Kudos
depping
Leadership
Leadership

it should not cause any problems. the upgrade also does not upgrade the VMFS. only new lun's / vmfs datastores will be 3.31.

Duncan

My virtualisation blog:

Reply
0 Kudos
milson
Enthusiast
Enthusiast

Did I miss it or has anyone found what the actual differences are between VMFS 3.21 and 3.31? Anything that matters?

Thanks!

Reply
0 Kudos
gdesmo
Enthusiast
Enthusiast

Then I guess I am wondering what the advantages/changes of 3.31 are? Is it worth creating new 3.31 lun's and migrating all my vm's.

Reply
0 Kudos
depping
Leadership
Leadership

I did not find any details on the vmfs update.

Duncan

My virtualisation blog:

Reply
0 Kudos
WillFulmer
Enthusiast
Enthusiast

Wanted to see if anyone has gotten any other info regarding this?

Reply
0 Kudos
williamarrata
Expert
Expert

I think the sVMotion might be the difference with a posibility in how the metadata id written and handled. BUT, this is just a guess.

Hope that helped. Smiley Happy

Hope that helped. 🙂
Reply
0 Kudos
christianZ
Champion
Champion

Discussed here: also.

Reply
0 Kudos
troberts
VMware Employee
VMware Employee

ESX Server 3.0.2 used VMFS 3.21 and ESX Server 3.5 uses VMFS 3.31. The differences between VMFS 3.21 and VMFS 3.31 are mainly internal architecture, bug fixes, and small block size support (as low as 128K). Upgrading from VMFS 3.21 to VMFS 3.31 is not possible without reformating the volume. However, you do not need to move the VMFS volume to 3.31 to run ESX Server 3.5. The volumes are compatible. In other words, you can not upgrade a VMFS volume from version 3.21 to 3.31, but you can still upgrade the ESX Server to ESX Server 3.5 and continue to run on a VMFS 3.21. This means you can also run VMs from ESX Server 3.0.2 directly on VMFS 3.31.

VMFS 3.31 in 3.5 introduced a distributed locking optimization - optimistic locking.

  • Basically, the actual acquisition of on-disk locks (involving SCSI reservations) is postponed as late as possible in the life cycle of VMFS metadata transactions.

  • Doing so allows the number and duration of SCSI reservations to be reduced, thereby reducing their impact on VM I/O and VMFS metadata I/O originating from other hosts that share the volume.

  • You may see the message - Optimistic Lock Acquired By Another Host - it means that a lock which was held optimistically (not yet acquired on-disk) during a transaction was found to have been acquired on-disk by a different host. In this case, we simply abort and retry the transaction.

Reply
0 Kudos
cfizz34
Contributor
Contributor

Do you have an article you can reference? We have many issues with SCSI reservations using the NetApp Filers and Cisco switches and do not have a resolution to why.

Reply
0 Kudos
RParker
Immortal
Immortal

VMFS 3.31 is no change from 3.21, probably some sort of behind the scenes maintenance patch. There is no need to upgrade it.

Reply
0 Kudos
RParker
Immortal
Immortal

I think the sVMotion might be the difference with a posibility in how the metadata id written and handled. BUT, this is just a guess.

Nope, doesn't matter. It works on both 3.21 and 3.31. If you install 3.03 and create a NEW datastore with any version after that you will see the new version, but there are no differences or changes.

Reply
0 Kudos
cfizz34
Contributor
Contributor

troberts can you debunk what RParker is stating. troberts do you have any supporting documentation to back up your claim that:

VMFS 3.31 in 3.5 introduced a distributed locking optimization - optimistic locking.

  • Basically, the actual acquisition of on-disk locks (involving SCSI reservations) is postponed as late as possible in the life cycle of VMFS metadata transactions.

  • Doing so allows the number and duration of SCSI reservations to be reduced, thereby reducing their impact on VM I/O and VMFS metadata I/O originating from other hosts that share the volume.

  • You may see the message - Optimistic Lock Acquired By Another Host - it means that a lock which was held optimistically (not yet acquired on-disk) during a transaction was found to have been acquired on-disk by a different host. In this case, we simply abort and retry the transaction.

Reply
0 Kudos
RParker
Immortal
Immortal

We have many issues with SCSI reservations using the NetApp Filers and Cisco switches and do not have a resolution to why.

It has nothing to do with VMFS 3.21 or 3.31. SCSI reservations are caused by having too many hosts on a LUN, too many vmdks on a LUN or too many open snapshots.

Netapp told us there is 256 handle limit on a particular LUN, and this isn't a VM thing, it's a Netapp LUN thing. It only becomes an issue because of the way virtualziation keeps many files open at once. Basically if you have 10 hosts. That's 10 connections. If each host has 10 VM's that is now 100. If you snapshot each VM now you are looking at 200 connections, already close to your limit. Then queue depth affects this so you don't have as much problem, but the reservation ONLY occurs WHEN changes are made to a file or the file is opened for read/writes. You should contact Netapp for this problem, because it has nothing at all to do with VMFS versions, it's the way you architected your ESX hosts.

Each HOST, and EACH file on EACH host and EACH snapshot in addition get a SCSI reservation.

Reply
0 Kudos
RParker
Immortal
Immortal

ESX Server 3.0.2 used VMFS 3.21 and ESX Server 3.5 uses VMFS 3.31

This is not fully correct. ESX Server 3.03 introduced VMFS 3.31. . I was in training class for ESX 3. just before version 3.5 came out. We didn't upgrade ANY of our ESX servers at that time. We did upgrade to 3.03, and ESX 3.03 introduced VMFS 3.31, not ESX 3.5. So VMFS 3.31 was before ESX 3.5. This came out in class because other people asked about it for ESX 3, and we all assumed it was a pre-cursor to 3.5 features, but it was there in 3.03.

Reply
0 Kudos
RParker
Immortal
Immortal

VMFS 3.31 in 3.5 introduced a distributed locking optimization - optimistic locking.

Actually 3.5 instroduced optimistic locking. But VMFS 3.21/3.31 is NOT your problem. The version of VMFS will not cause the issues. I can use 3.5 on a VMFS 3.21 volume just fine, because we have not converted most of our VMFS volumes over yet (they are still on VMFS 3.21). We have Netapp just like you and we don't have SCSI reservation issues.

Reply
0 Kudos
cfizz34
Contributor
Contributor

What make/modle of NetApp Filers are you using? What version of OnTap? Are you using iSCSI or Fiber? What kinds of switches ar you using?

Reply
0 Kudos