eugen at imacandi.net
Thu Feb 20 20:09:24 UTC 2014
On Thu, Feb 20, 2014 at 9:49 PM, Dan Shoop <shoop at iwiring.net> wrote:
> On Feb 20, 2014, at 1:48 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> > The locking restrictions are for your own protection. If the filesystem
> > inside your virtual disks is not a clustered filesystem;
> > two instances of a VM simultaneously mounting the same NTFS volume and
> > writing some things, is an absolute disaster.
> > Under normal circumstances, two applications should never be writing to
> > the same file. This is true on clustered filesystems.
> > This is true when running multiple applications on a single computer.
> Why should "two applications should never be writing to the same file"? In
> a real clustered *file*system this is exactly what you want. The same
> logical volume mounted across host cluster members, perhaps geodistantly
> located, each having access at the record level to the data. This permits
> HA and for the application to be distributed across cluster nodes. If a
> host node is lost then the application stays running. If the physical
> volume is unavailable then logically shadowing the volume across node
> members or storage controllers / SANs permits fault tolerance. You don't
> need to "fail disks over" (really logical volumes) as they are resilient
> from the start, they just don't fail. When the shadow members return they
> replay journals or resilver if the journals are lost.
There is a lot of misunderstanding here about how ESXi works in a multiple
There are a lot of abstraction layers.
Physical disk -> VMFS -> VMDK files that represent the VM HDD -> VM -> VM
filesystem (NTFS, ext3/4, xfs etc).
The physical disk can be whatever device a controller presents (like a 4
way FC connection for the same LUN).
What we are discussing here is the VMFS capabilities.
Also, what I am saying is that the VM will be very upset when it's HDD
contents are changed without notice. This is why ESXi has a lock per VM
that notifies other ESXi hosts trying to access a particular VM folder that
"hey, it's in use, leave it alone".
And speaking of clustered filesystems, while you may read/write on the at
the same time, except for file storage I do not know of any application
that has no objections that the files it works with have their contents
modified - think database systems.
> I'd note that this can be accomplished just so long as you have a common
> disk format across the OS nodes.
> These problems were all resolved 40 years ago in mainframe and supermini
> systems. They're not new. VMware has been slowly reinventing -- more
> accurately rediscovering -- well known HA techniques as it's trying to
> mature. And it still has a lot of catching up to do. It's the same tale
> that microcomputers have been doing for decades as they've come into use as
Depending on the use case you may be right or wrong :)
> However I'm not sure what all of this has to do with network operations. ;)
What, you want political discussions instead? :)
More information about the NANOG