Hi everyone,
has anybody do that - not clear for me, what steps needed here.
Regards
Christian
As far as I know you can't upgrade and it's just a matter of formatting the datastore with a 3.5/3i host to get a vmfs 3.31. I have a 3.0.1 host in test that can use a 3.31 datastore (on iSCSI) just fine it seems.
As far as I know you can't upgrade and it's just a matter of formatting the datastore with a 3.5/3i host to get a vmfs 3.31. I have a 3.0.1 host in test that can use a 3.31 datastore (on iSCSI) just fine it seems.
I dont think you can upgrade.
If you have enough disk space then you could create another datastore using ESX 3.5, and then use svmotion to migrate the virtual machines from the VMFS 3.21. datastore to the new VMFS 3.31 datastore.
Having said all of that, Im not sure, and have never seen what the benefits are of having a 3.31 datastore.
I agree with you, I have also not seen any new benefits with VMFS 3.31. So, not knowing those benefits, I would not risk VMFS upgrade, if I had vm's on that filesystem. If I did not have VM's on the filesystem, I would create a new datastore instead of trying to upgrade.
Thanks to all for your replies.
As Dave mentioned it is not possible to upgrade the VMFS (3.21 -> 3.31) - so we decided to create new volumes (with 3.31 - it is possible that in future there will be new features need the vers .3.31) and we will clone all our vms into it.
That all needs time and an additional space - so you can't do it all at once. After cloning all vms from one old volume ( 3.21) we will deleted that volume.
Because of storage virtualization here the empty space goes back to our storage pool and can be reused for new volumes.
In the mentioned doc that issue wasn't described clearly.
I don't know if anyone has mentioned this, bu there is no compelling reason to update to 3.31, so why even bother to create a new Volume just for the purpose of changing the version of VMFS?
Everything works, svmotion, migrate, snapshots.. so what is the point?
And IF Vmware makes a change to VMFS, I doubt very seriously that it will be backwards compatible like it is now, so they will make a new version 4.00 VMFS, so you will end up doing this again when or if they update the VMFS version.
It's just like NTFS, there really hasn't been any significant changes, other than GUID, which you can upgrade to, you just can use previous versions of Windows with the NTFS update.
Basically you are right - but we have now a good chance to do that because we got new esx hosts and a new storage unit - so now we have space and resources for such migration - so we want to put all the things to the newest vesions before we start with new vms.
I don't know if anyone has mentioned this, bu there is no compelling reason to update to 3.31, so why even bother to create a new Volume just for the purpose of changing the version of VMFS?
Here's a huge compelling reason to move to VMFS 3.31, distributed locking optimizing in the form of optimisic locking, for those of us that see lots of SCSI reservation issues (quoting from http://communities.vmware.com/message/963043;jsessionid=7AC7B31D4BF678B3E0653EBF1C8667F2#963043)
>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.