1. Reusing old features to build new ones
Step by Step
Reusing old features to build new ones
Allon Mureinik
Supervisor, RHEV Storage
Red Hat
DevConfCZ, Feb 2015

2. Old school software development
We go through a rigorous process of defining the full scope of the requirements, designing to answer every need, implement it, test, re-test, test again until we have a perfect feature...

3. And when you're all set and done
… And you end up with a white elephant, which is too expensive to maintain, and usually serves no useful purpose.

4. An alternative approach
I intend to show the step-by-step approach, where insurmountable features are broken down to smaller parts, and each part has it's own benefits.

5. Case study – oVirt Live Merge

6. What Is oVirt?
Large scale, centralized management for server and desktop virtualization
Based on leading performance, scalability and security infrastructure technologies
Provide an open source alternative to vCenter/vSphere
Focus on KVM for best integration/performance
Focus on ease of use/deployment

7. oVirt: Not a Single Project
Incubation Projects
MOM
moVirt
Test Projects
… your contributions are welcome!
See for details
oVirt-Engine
VDSM
oVirt-Node
ovirt-Engine-SDK
oVirt-Engine-CLI
oVirt-Guest-Agent
oVirt-Image-Uploader
oVirt-iso-Uploader
oVirt-Log-Collector
oVirt-DWH
oVirt-Reports

8. Some architecture...

9. Live Snapshot Capture disks and memory at a point in time
Implemented using qcow2 volume chains
Usages
Save the state before a major change
Can be previewed or reverted
VM live backup
Live Storage Migration
What is it?
- a consistent point in time
Implementation:
- currently Qcow2, looking forward to Qcow3.

10. The next logical step...
Bug Support live deletion of a snapshot / live-merge
Reported against RHEVM (Oct. 2010)
27 customer tickets
So what's the big deal?

11. An actual conversation...

12. An actual conversation...

13. An actual conversation...

14. An actual conversation...

15. Problem 1 – What if a merge fails?

16. Problem 1 – What if a merge fails?

17. Solution 1 – Single Disk Snapshots

18. Problem 2 – long running tasks...
Up to 3.5.0, oVirt has two kinds of verbs to communicate with VDSM:
Synchronous verbs
Finish in under 3 minutes
Give result immediately
Asynchronous
May take a long time to complete
Return a task to be monitored
Only run on SPM
Engine commands have up to 3 stages
executeAction() - Synchronous database + VDSM
Poll the task until it completes (or fails)
endSuccefully() / endWithFailure()

19. Solution 2 - SEAT
A mechanism was added for Serial Execution of Asyncronous Tasks
_Asynchronous_Tasks
Allows creating chains of actions:
execute
poll for a task
move to the next execution...
... or rollback everything

20. Solution 2 – Why would I even...
Live Storage Migration
Migration
Utilizes SEAT for a series of tasks:
[Live Snapshot – not mandatory]
Clone image structure
Start syncing active image
Sync backing chain
Stop sync
Remove (and wipe) source

21. Problem 3 – Still only SPM tasks
Up to 3.5.0, only SPM can run asynchronous tasks
This is due to the requirement to persist task info on the master domain

22. Solution 3 – HSM “Tasks”
Separate the coordination code from the polling code
oordinator
Report the progression of the block job on the pooled VM stats
Now the HSM that runs the VM can run the merge verb
The basis for rewriting VM migration
The basis for removing the SPM completely
Come here all about it in DevConfCZ 2016!

23. A quick shoutout

24. THANK YOU! Feedback appreciated: http://devconf.cz/f/79 Stay in touch:
@mureinik
Patches welcome: