Bug 854964 - [Storage] There is a scenario when VM might have several bootable disks which is wrong.
Summary: [Storage] There is a scenario when VM might have several bootable disks which...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
: 3.2.0
Assignee: Allon Mureinik
QA Contact: Leonid Natapov
URL:
Whiteboard: storage
Depends On:
Blocks: 948448
TreeView+ depends on / blocked
 
Reported: 2012-09-06 12:02 UTC by Leonid Natapov
Modified: 2022-07-09 06:03 UTC (History)
16 users (show)

Fixed In Version: sf11
Doc Type: Bug Fix
Doc Text:
Previously, it was possible to accidentally attach more than one bootable disk to a virtual machine, by having a shared disk and changing its state to bootable after attaching it to a machine with an existing bootable disk. This prevented the virtual machine from running. Now, when attempting to make a disk bootable, a check is in place to ensure it is not attached to a virtual machine with an existing bootable disk. If there is no existing bootable disk, the operation succeeds. Otherwise, editing the disk will fail with the following error message: "Cannot ${action} ${type}. Disk ${DiskName} in VM ${VmName} is already marked as boot."
Clone Of:
Environment:
Last Closed: 2013-06-10 21:10:06 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
scohen: Triaged+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-47124 0 None None None 2022-07-09 06:03:51 UTC
Red Hat Knowledge Base (Solution) 320683 0 None None None Never
Red Hat Product Errata RHSA-2013:0888 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.2 update 2013-06-11 00:55:41 UTC
oVirt gerrit 12889 0 None None None Never

Description Leonid Natapov 2012-09-06 12:02:01 UTC 
[Storage] There is a scenario when VM might have several bootable disks which is wrong.

How to reproduce:
1.Create several VMs with regular (not shared) disks and mark this disk bootable.
You must have several VMs,each of them has 1 bootable disk.
2.Create shred disk.
3.Attach this shared disk to all VMs.
4.Go to one of the VMs,delete its bootable disk and after that mark its shared disk as bootable.

Now,all other VMs that already has one bootable disk will also have shared disk that will be marked as bootable.
Comment 1 Ayal Baron 2012-09-13 12:44:03 UTC 
Solving this requires moving the bootable property from disk to VM-disk relationship.
Comment 3 Allon Mureinik 2013-02-27 09:19:33 UTC 
(In reply to comment #1)
> Solving this requires moving the bootable property from disk to VM-disk
> relationship.

Moving the bootable property to the device instead of the disk is generally the correct way to go, but in the meanwhile, we can have a CDA that checks updating the bootable property of a (shared) disk.
Comment 8 Allon Mureinik 2013-03-03 17:34:00 UTC 
(In reply to comment #3)
> (In reply to comment #1)
> > Solving this requires moving the bootable property from disk to VM-disk
> > relationship.
> 
> Moving the bootable property to the device instead of the disk is generally
> the correct way to go, but in the meanwhile, we can have a CDA that checks
> updating the bootable property of a (shared) disk.

Ayal, we can solve this, relatively easily, for disks only.
Please devel ack/nack this direction.
Comment 9 Ayal Baron 2013-03-03 18:50:02 UTC 
(In reply to comment #8)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Solving this requires moving the bootable property from disk to VM-disk
> > > relationship.
> > 
> > Moving the bootable property to the device instead of the disk is generally
> > the correct way to go, but in the meanwhile, we can have a CDA that checks
> > updating the bootable property of a (shared) disk.
> 
> Ayal, we can solve this, relatively easily, for disks only.
> Please devel ack/nack this direction.

Does this mean that setting bootable on a shareable disk would check to see if it's attached to other VMs and prevent it or does it mean that we would not support bootable shareable disks? (the former is fine, the latter is not).
Comment 10 Allon Mureinik 2013-03-04 06:48:28 UTC 
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #3)
> > > (In reply to comment #1)
> > > > Solving this requires moving the bootable property from disk to VM-disk
> > > > relationship.
> > > 
> > > Moving the bootable property to the device instead of the disk is generally
> > > the correct way to go, but in the meanwhile, we can have a CDA that checks
> > > updating the bootable property of a (shared) disk.
> > 
> > Ayal, we can solve this, relatively easily, for disks only.
> > Please devel ack/nack this direction.
> 
> Does this mean that setting bootable on a shareable disk would check to see
> if it's attached to other VMs and prevent it or does it mean that we would
> not support bootable shareable disks? (the former is fine, the latter is
> not).

The former.
When we edit a disk's properties in a VM context, it's bootable flag is checked only vs. the contextual VM - this should be changed to all of the VMs.
Comment 12 Dafna Ron 2013-04-09 09:34:33 UTC 
verified on sf13 - we cannot edit the boot tab if the disk is shared on multiple vm's with already existing shared disks
Comment 13 Dafna Ron 2013-04-09 09:45:28 UTC 
verified on sf13 - we cannot edit the boot tab if the disk is shared on multiple vm's with already existing shared disks
Comment 15 errata-xmlrpc 2013-06-10 21:10:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0888.html
Note You need to log in before you can comment on or make changes to this bug.