Bug 1084103

No reason to block this option since this is by design, one can have a bootable disk on one VM yet have it shared as a regular disk on another VM without any complications, having the same disk shared and bootable on multiple VMs might pose some problems indeed but as in every shareable disk this is the user's responsibility to use this option cautiously.

If the reason for not blocking this, is because this is the design then the design is wrong.
The scenario you mentioned is impossible. There is no option to share a bootable disk as regular disk on another vm.
It will complain that the disk you are trying is already marked as boot.
This attribute (boot) is Disk's attribute and not per attach so it is impossible to select the disk as regular for the other vm.

Indeed, this is a loose end, that was not covered in the 3.2 fix... 
[See Bug 854964 - [Storage] There is a scenario when VM might have several bootable disks which is wrong]

Sean

I don't see a problem with this behavior - several VMs share a boot disk, and each can have its own data disk.

Sean - up to you.

Sean, can you please answer the question on comment #4 the meaning of the fix will be that vms will not start, and the user will not know exactly what happened.

i also think that its possible to share the boot disk between vms, i dont understand how it can be corrupted, i thought shared is readonly

(In reply to Omer Frenkel from comment #5)
> i also think that its possible to share the boot disk between vms, i dont
> understand how it can be corrupted, i thought shared is readonly
"shared" and "readonly" are orthogonal - you may very well have a shared r/w disk. In such a case, it's up to the user to ensure that multiple writes won't corrupt the disk (e.g., by using a clustered filesystem).

Having said that, I agree with Omer that this may be overthinking it. Under the philosophy of "don't nanny the user", we leave this configuration enabled, and allow "power" users who know what they're doing to utilize it.

I'd support more freedom as well. We have a bad past experience when trying to outsmart the users:)

(In reply to Omer Frenkel from comment #5)
> Sean, can you please answer the question on comment #4 the meaning of the
> fix will be that vms will not start, and the user will not know exactly what
> happened.
> 
> i also think that its possible to share the boot disk between vms, i dont
> understand how it can be corrupted, i thought shared is readonly

Freedom is good, but we also need to protect the user from ending up in a corrupted state.

This can be solved of course with the proper warning, to minimize human errors.

Sharing a bootable does has it use cases, as clustering configurations etc.
The point is the admin need to select this option for a reason and be aware of its possible implications.

Sean

(In reply to Sean Cohen from comment #9)
> (In reply to Omer Frenkel from comment #5)
> > Sean, can you please answer the question on comment #4 the meaning of the
> > fix will be that vms will not start, and the user will not know exactly what
> > happened.
> > 
> > i also think that its possible to share the boot disk between vms, i dont
> > understand how it can be corrupted, i thought shared is readonly
> 
> Freedom is good, but we also need to protect the user from ending up in a
> corrupted state.
> 
> This can be solved of course with the proper warning, to minimize human
> errors.
> 
> Sharing a bootable does has it use cases, as clustering configurations etc.
> The point is the admin need to select this option for a reason and be aware
> of its possible implications.
> 
> Sean

OK - so we're going to allow this, and issue a warning.
Sean - please provide the text you want there.

The issue existed since 3.1 and we received exactly 0 customer tickets or upstream user reports on it.

Since this isn't getting any traction on the needinfo (see comment 10), pushing out to 3.6.0 until we get a decision.

Closing, not worth the hassle.