Thank you for your answer Scott.
As stated in the initial opening question, the disk does have a snapshot applied to it.
So placing the matter the other way around:
Should the -flat.vmdk file be not readable, even though the virtual disk has a snapshot, be considered a bug?
Or, blocking reads on -flat.vmdk files that do have a snapshot above is a new design approach from part of VMWare?
Thanks on advance
I have not seen or heard of anything specific to vSphere 7 about the snapshot behaviour, but given that the host running the VM only needs read access to the parent disk (flat.vmdk) after a snapshot has created a child disk I see no reason to be concerned.
Create a second-level snapshot and see if the child disk from the first-level snapshot also has a read lock applied to it by the host.
My guess is that the lock is a preventative measure which reduces the chance of snapshot corruption.
flat.vmdks should not be locked when the VM has an active snapshot.
But the locking procedures dont work as reliable as they are supposed to so I assume you hit a flaw.
I really must apologize Scott. I believe my English (it's not my mother tongue) is not good enough to transmit the idea.
As posed in my two previous posts, the VM has indeed created a snapshot and therefore a child disk.
I have also tried to perform the same operation (a short read) on the -flat.vmdk file after taking a second snapshot, still the same behaviour is observed.
I am not talking about the snapshot files, which, of course, must be protected to avoid corruption. I am insistingly referring to the -flat.vmdk file.
Thank you Continuum:
AFAIC the -flat.vmdk lock has been released quite reliably for us in all previous versions. I believe this is a bug, nonetheless there are other type of concerns related to this eventual bug, as keeping the -flat.vmdk file locked would prevent users from backing up their -flat.vmdk files from the shell while the VM is on.
forget my last post.- I spoke too early and should have looked into it first.
You are right
This is the second radical change in behaviour of the new VMFS-version that comes with ESXi 7 that I notice.
First one is "expanding systemfiles on the fly"
Both behaviour changes are completely unexpected and both of them make zero sense.
I reported the first one before the release but did not noticed this one until now.
VMware should explain the new functionality.
I understand the point you were making now.
Sorry to bother you again Continuum, but I believe this to be relevant for the thread.
As per our tests and the feedback provided by our users, this blocks on the flat.vmdk files (always when the VM is running on a snapshot) observed in ESXi 7.0.0 seem to be random, which is double puzzling. What I mean is that some -flat.vmdk files are read just fine, while others are blocked, this is in the same host and under the exact same circumstances.
This opens again the door to believe that it could be a bug instead of intentional, although being intentional would still make sense, some apparently random behaviour points at a possible bug.
(*) I deleted my previous post, as it doesn't make sense to offer my opinion on something that I still can't grasp to comprehend.
I'm afraid that it's unfortunately not a bug, but by idesign.
From this weeks Veeam newsletter:
... The issue is caused by a change in vSphere 7: it now locks ALL delta files in the snapshot chain for exclusive access. Previous vSphere versions did not lock read-only delta files exclusively, ...
From that, I assume that all .vmdk files (flat, delta, sesparse) in the snapshot chain are locked now.
Nice find... but if this were to be an intentional behavior how would backup products behave then? Is it different when requesting to read it using VADP.... ?
As a backup admin, I get a little bit concerned even though we're not running vSphere 7.... yet.
Well probably Veeam has first hand information, or maybe they just observed the same thing.
Vmkfstools being able to access those -flat.vmdk files without issue is an indication that the new behaviour is there by design.
But, why would VMWare do such a nasty thing?, ESXi is in the end an OS.
That's looks like a way to fence off SME's and encourage them to buy a license. Nonetheless not very wise, as can backfire with a drop in the use of Free version. Anyway...
The new locking procedures also disables several of the workarounds we used to repair VMs with previous versions.
This does not only affect users of the free ESXi but it seriously affects all ESXi users.
Another example: in previous versions we could create linked clones manually - that will no longer work.