Arik Hadas <ahadas@redhat.com> writes:
Right, but let's be fair and present the benefits of v2v-jobs as well: 1. it is the simplest "infrastructure" in terms of LOC 2. it is the most efficient mechanism in terms of interactions between the engine and VDSM (it doesn't require new verbs/call, the data is attached to VdsStats; probably the easiest mechanism to convert to events) 3. it is the most efficient implementation in terms of interaction with the database (no date is persisted into the database, no polling is done)
Currently we have 3 mechanisms to report jobs: 1. VM jobs - that is currently used for live-merge. This requires the VM entity to exist in VDSM, thus not suitable for virt-sysprep. 2. storage jobs - complicated infrastructure, targeted for recovering from failures to maintain storage consistency. Many of the things this infrastructure knows to handle is irrelevant for virt-sysprep flow, and the fact that virt-sysprep is invoked on VM rather than particular disk makes it less suitable. 3. V2V jobs - no mechanism is provided to resume failed jobs, no leases, etc
I have some arguments for using V2V-like jobs [1]: 1. creating template from vm is rarely done - if host goes unresponsive or any other failure is detected we can just remove the template and report the error 2. the phase of virt-sysprep is, unlike typical storage operation, short - reducing the risk of failures during the process 3. during the operation the VM is down - by locking the VM/template and its disks on the engine side, we render leases-like mechanism redundant 4. in the worst case - the disk will not be corrupted (only some of the data might be removed).
So I think that the mechanism for storage jobs is an over-kill for this case. We can keep it simple by generalise the V2V-job for other virt-tools jobs, like virt-sysprep.
[1] I believe that as Moran and Yaniv noted, we can just do it in the create template flow without the intermediate (POC) stage of having an operation for doing that on existing VM or template - it only complicates stuff
Nice summary. Based on the arguments you provide the v2v-like way looks like a good solution. Providing we can attach the operation to the create template flow it should be safe and simple.
On Mon, Dec 5, 2016 at 10:05 AM, Nir Soffer <nsoffer@redhat.com> wrote:
We can do:
1. Add jobs with multiple volumes leases - can make error handling very complex. How do tell a job state if you have multiple leases? which volume generation you use?
2. Use volume job using one of the volumes (the boot volume?). This does not protect the other volumes from modification but engine is responsible for this.
These two don't look like options worth to bother with.
3. Use new "vm jobs", using a vm lease (should be available this week on master). This protects a vm during sysprep from starting the vm. We still need a generation to detect the job state, I think we can use the sanlock lease generation for this.
If we can perform virt-sysprep within the create template flow, does this option provide any real benefit over what Arik suggests? Would it simplify things or add complexity to the proposed solution?