KVM and Xen Disk Management Parity

Registered by Paul Voccio

This is feedback from the session at the Essex Summit to achieve disk management parity between KVM and XenServer and to provide the model for other hypervisors to be compatible in how they manage disk images within the hypervisor.

The amenable solution agreed upon at the summit was to add a second disk column to the instances_type table. This would allow service providers to have different operating systems configured differently and provide a consistent view across OpenStack. Using python-novaclient, a current nova flavor-list returns the following fields.

+----+--------------+-----------+------+----------+-------+------------+----------+
| ID | Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Quota | RXTX_Cap |
+----+--------------+-----------+------+----------+-------+------------+----------+

By adding an additional disk field, operators would be able to utilize this field to show customers how the disks would be configured between instance-types. For example:

+----+--------------+-----------+------+----------+-------+------------+----------+
| ID | Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Quota | RXTX_Cap |
+----+--------------+-----------+------+----------+-------+------------+----------+
| 1 | 256 slice | 256 | 0 | 10 | 1 | 150 | 10 |
| 2 | 512 slice | 512 | 0 | 20 | 1 | 300 | 20 |

Could be represented as:

+----+--------------+-----------+------+----------+-------+------------+----------+
| ID | Name | Memory_MB | Swap | Disk1_GB | Disk2_GB| VCPUs | RXTX_Quota | RXTX_Cap |
+----+--------------+-----------+------+----------+-------+------------+----------+
| 1 | 256 slice | 256 | 0 | 10 |30 | 1 | 150 | 10 |
| 2 | 512 slice | 512 | 0 | 20 |60 | 1 | 300 | 20 |
| 3 | 256 slice | 256 | 0 | 40 |0 | 1 | 150 | 10 |
| 4 | 512 slice | 512 | 0 | 80 |0 | 1 | 300 | 20 |

In the above example, ID 1 would have a primary disk of 10gb allocated and a secondary disk of 30gb allocated. if the user resized to ID 2, both the primary and the secondary partition would grow accordintly. If the user then resized to ID 3, the primary disk would grow to 40gb and the secondary disk would be dropped from their configuration.

***The secondary disk would be considered ephemeral and would not be included in system snapshots or included in the disk images coming from Glance. ***

Blueprint information

Status:
Complete
Approver:
Vish Ishaya
Priority:
Essential
Drafter:
Nova Feature Parity Team
Direction:
Approved
Assignee:
Johannes Erdfelt
Definition:
Approved
Series goal:
Accepted for essex
Implementation:
Implemented
Milestone target:
milestone icon 2012.1
Started by
Vish Ishaya
Completed by
Thierry Carrez

Related branches

Sprints

Whiteboard

looks good. I think we probably want to have two different names for the storage so it is clear that one of them is ephemeral (not snapshotted)

Gerrit topic: https://review.openstack.org/#q,topic:bp/disk-configuration-parity,n,z

Addressed by: https://review.openstack.org/2918
    KVM and XEN Disk Management Parity

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.