VMware Cloud Community
jappenroth
Enthusiast
Enthusiast
Jump to solution

How to protect a raw disk from access by multiple VMs?

Hello,

I am not sure wether to put this in the VC, VM or ESX Configuration forum, but since this one seems to be the most frequented forum I just put it here. Smiley Happy

Is there any way to prevent a second virtual machine from accessing an raw LUN that is used by another VM (powered on!!!) by means of an RDM?

Obviously, if I have the two VMs on the same ESX host, I am prevented from powering on the second VM or even assigning the same raw disk to this VM. On the other hand, if I put those two VMs on different ESX hosts, Virtual Center does not prevent me from assigning the raw disk twice and I can even power on the second VM and write to the disk. This will of course result in a totally inconsistent file system at the raw disk.

It does not matter which mode I choose, virtual mode as well as physical mode, both have the same effect. Since I snapshots are required, physical mode would not be an option anyway.

So is there any option to prevent this?

Regards,

Jan

Reply
0 Kudos
1 Solution

Accepted Solutions
bertdb
Virtuoso
Virtuoso
Jump to solution

per-VM zoning won't be available until NPIV is fully supported, and it isn't in the current ESX 3.0 series.

View solution in original post

Reply
0 Kudos
5 Replies
ianmellor
Enthusiast
Enthusiast
Jump to solution

Hi,

Not sure what you are trying to do but RDM have distributed file locking. The RDM appears to the VM as a normal file. You will not be able to have two VM's writing to the same RDM.

Distributed File Locking – RDM makes it possible to use VMFS distributed

locking for raw SCSI devices. Distributed locking on an RDM makes it safe to use

a shared raw LUN without losing data when two virtual machines on different

servers try to access the same LUN.

You cab read this doc, on page 151 is RDM's

http://www.vmware.com/pdf/vi3_301_201_server_config.pdf

Hope this helps.

bertdb
Virtuoso
Virtuoso
Jump to solution

per-VM zoning won't be available until NPIV is fully supported, and it isn't in the current ESX 3.0 series.

Reply
0 Kudos
jappenroth
Enthusiast
Enthusiast
Jump to solution

Hi ianmellor,

I do not want to do this! I just found out that it is possible and wonder how to prevent this from happening to avoid disaster.

I read the docs and was wondering about the distributed file locking part. I guess it just means that the RDM file itself is protected which is true. So if you add the mapping file to a second VM, you can not power on this VM which is perfectly okay.

But I can assign the same raw LUN to a second VM on another ESX host just by creating a new mapping file and pointing to this LUN. The VM will start and even has write access to the LUN as described above.

There should be some mechanism to prevent this.

Jan

Message was edited by:

jappenroth

Message was edited by:

jappenroth

Reply
0 Kudos
paulo_meireles
Jump to solution

But I can assign the same raw LUN to a second VM on another ESX host just by creating a new mapping file and pointing to this LUN.

So, don't. There is no technical answer for your question, meaning there is no "technical feature" that would prevent it from happening. However, you may change your working methods to make that impossible to happen: just create a single RDM to the LUN (instead of one instance per VM), and reuse it in the several VMs. This way, filelocks will prevent the RDM from being used by several VMs.

Paulo

jappenroth
Enthusiast
Enthusiast
Jump to solution

Hi guys,

thanks for the input, I distributed points to you all.

So I guess my only possibility to protect the raw disks is to use roles and permissions to avoid raw disks from being mistakenly added to a second VM and then the file system being destroyed.

At least I have the possibility to deny the "raw device" permission from all roles and create a special role for the manipulation of raw device settings.

In that case anybody who wants to edit raw disk settings would have to use this special account and therefore would be remembered to be cautious which raw disk to add to which VM.

Jan

Reply
0 Kudos