Today I've merged the last patch of a feature that changes the disks entities in oVirt. 

Up until now any disk entity (image, LUN etc.) contained properties of whether it is a boot disk and what disk interface it should be connected with (IDE, VirtIO etc.).

The old design might have made some sense in earlier versions since back then it was not possible for a disk to be connected to a few VMs at once. in later versions, with the introduction of sharable disk and the introduction of a disk snapshot attachment to a VM this made less sense and created a very big limitation given the fact that you could not have a disk connected as a bootable to on VM and not bootable on another or connected to one VM via IDE and to the other with VirtIO.

From version 4.0 as a part of a larger scale refactoring of the disk entities throughout oVirt, the boot and interface properties are now defined per VM and in light of this do not exist for a floating disk (i.e. a disk which is not connected to any VM) and thus have to be specified upon creating/attaching a disk for a VM.

Before I'll get to the changes and specifics, I'd like to ask all you developers and users that if you encounter any faults or exceptions (especially surrounding the %Disk% entities and specifically DiskVmElement) please contact me or better yet - open a bug and assign to me.

This change pretty much involves every storage related flow in oVirt and while I've verified extensively there'll always be corner cases that might fail.

Now you're probably asking for the bottom line,  given those changes what will change in the "outer" behavior of  oVirt?

The Webadmin changes are quite intuitive, you will notice when creating a new floating disk the mentioned properties need not be specified and since they do not exist before a disk is attached to a VM they will need to be specified upon the attachment (see screenshot).

Note that as mentioned above the properties defined will be specific ONLY for that VM and of course the same limitation that once existed still apply such as matters of maximum number of controllers, single bootable disk per VM and so on.

The real API change is in the REST, a new type called DiskAttachment was introduced to define how a disk is connected to a VM, I'll give some examples to clarify as most of you will probably have to change your scripts accordingly:

No change here just note that bootable and interface properties will be ignored

Will now be done through api/vms/{vm_id}/diskattachments - the request body should contain the diskattachment containing the bootable and interface properties and the disk inside it (as in the old API, no disk ID should be specified):

Will be through api/vms/{vm_id}/diskattachments - the request body should contain the diskattachment containing the bootable and interface properties and the disk inside it with ID only:

Will be through api/vms/{vm_id}/diskattachments/{disk_id} -  the request body should contain the diskattachment containing the bootable and interface properties if they need updating and the disk inside it with properties that need updating, this will change the interface to IDE, make the disk bootable and update the disk alias:

When getting a disk which is not attach to a VM via api/disks or api/disks/{disk_id} the aforementioned properties will not appear simply because of the fact that they do not exist anymore, for disks attached to a VM via api/vms/{vm_id}/disks or api/vms/{vm_id}/disks/{disk_id} the behavior will stay the same.

This pretty much sums it all, I'd like to thank jhernandaz for the great help with the REST part and to derez and amureini for their help in reviewing.

Please don't hesitate to contact me if you have any questions.