[ovirt-devel] Major changes in the disk entities in oVirt Engine

[Tal Nisan]

Hi everyone,

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:


*Creation of a floating disk*

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

*Creation of a VM disk*

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):

<disk_attachment>
    <disk>
        <alias>Alias</alias>
        <provisioned_size>1073741824</provisioned_size>
        <format>cow</format>
        <storage_domains>
            <storage_domain id="53ef639c-0b27-46e0-827e-b64ebfffe28f"/>
        </storage_domains>
    </disk>
    <bootable>false</bootable>
    <interface>virtio</interface>
</disk_attachment>

*Attach a disk to VM*

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:

<disk_attachment>
    <disk id="8871306b-56da-4443-bd05-2a1974580517"/>
    <bootable>false</bootable>
    <interface>virtio</interface>
</disk_attachment>

*Update a VM disk*

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:

<disk_attachment id="8871306b-56da-4443-bd05-2a1974580517">
    <bootable>true</bootable>
    <interface>IDE</interface>
    <disk>
        <alias>MyNewAlias</alias>
    </disk>
</disk_attachment>

*"Getting" a disk*

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160519/66380f1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2016-05-18 10-44-38.png
Type: image/png
Size: 217829 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160519/66380f1d/attachment-0001.png>