VMware Cloud Community
VirtualizedEddi
Contributor
Contributor
Jump to solution

Why is disk.enableuuid=TRUE not the default?

Hi,

I was wondering why disk.enableuuid disk.enableuuid=TRUE is not the default.

What are the disadvantages of having this option?

It allows you to map the vmdk to the guest OS disk and allows for better management of disks.

Since this is a setting in the vmx I would have to reboot all the vm's where I want to do this.

is there a way to have this setting as a default when creating new vm's?

What are the dangers of setting this section?

I think if you would mount a snapshot disk to the same vm the OS would detect the same UUID and bad stuff happens?

I also read somewhere this might increase the unable to quiesce messages?

What do you guys think?

1 Solution

Accepted Solutions
dariusd
VMware Employee
VMware Employee
Jump to solution

[EDIT: Huh, scott28tt​'s post just before mine seems to suggest that my information about the default setting might be out-of-date!]

From my quick bit of research here, it seems the risks around disk.enableuuid=TRUE mostly involve cloning.

If a VM with disk UUIDs enabled is cloned, and if we do not give the clone's disk a new disk UUID, there is a risk of disk management software – such as remote backup software – becoming confused about the disks to be backed up, and failing to back up data.  If a VM with disk UUIDs enabled is used as a template, all of its deployed clones may end up sharing the same disk UUID.

If a VM with disk UUIDs is live-cloned (while it is powered on), it will be challenging for us to give the disk a new UUID in the clone.

If a VM with disk UUIDs enabled is cloned, and if we do give the clone's disk a new disk UUID, there is a risk that the OS will complain about the change of disk UUID when it boots, either by identifying the disk as a truly "new" disk and failing to understand that it is really the same disk as it has had prior to the clone (detecting new hardware, assigning new mount points/drive identifiers), or by simply failing to boot (e.g. Linux guests configured to identify partitions by disk UUID).

Disabling UUIDs by default avoids all of these risk factors.

We can not tell in advance which VMs are going to be cloned.  In previous discussions on the topic, it seems the risks of enabling disk UUIDs have been deemed sufficient for us to leave disk UUIDs disabled by default for most (all?) configurations.

I do not have an answer for setting it by default, nor about the quiesce messages.

--

Darius

View solution in original post

2 Replies
scott28tt
VMware Employee
VMware Employee
Jump to solution

According to documentation and KB articles, "true" has been the default for a long while now: VMware Knowledge Base

Two possible causes why it would be "false":

  1. Deploying VMs from a template in which the parameter was set to "false"
  2. Creating a new VM on a standalone host using the Host Client: VMware Knowledge Base

Useful article: Setting disk.enableUUID=true in vSphere Data Protection - VMware Support Insider


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
dariusd
VMware Employee
VMware Employee
Jump to solution

[EDIT: Huh, scott28tt​'s post just before mine seems to suggest that my information about the default setting might be out-of-date!]

From my quick bit of research here, it seems the risks around disk.enableuuid=TRUE mostly involve cloning.

If a VM with disk UUIDs enabled is cloned, and if we do not give the clone's disk a new disk UUID, there is a risk of disk management software – such as remote backup software – becoming confused about the disks to be backed up, and failing to back up data.  If a VM with disk UUIDs enabled is used as a template, all of its deployed clones may end up sharing the same disk UUID.

If a VM with disk UUIDs is live-cloned (while it is powered on), it will be challenging for us to give the disk a new UUID in the clone.

If a VM with disk UUIDs enabled is cloned, and if we do give the clone's disk a new disk UUID, there is a risk that the OS will complain about the change of disk UUID when it boots, either by identifying the disk as a truly "new" disk and failing to understand that it is really the same disk as it has had prior to the clone (detecting new hardware, assigning new mount points/drive identifiers), or by simply failing to boot (e.g. Linux guests configured to identify partitions by disk UUID).

Disabling UUIDs by default avoids all of these risk factors.

We can not tell in advance which VMs are going to be cloned.  In previous discussions on the topic, it seems the risks of enabling disk UUIDs have been deemed sufficient for us to leave disk UUIDs disabled by default for most (all?) configurations.

I do not have an answer for setting it by default, nor about the quiesce messages.

--

Darius