[ovirt-devel] [VDSM] Correct implementation of virt-sysprep job

[Milan Zamazal]

Arik Hadas <ahadas at 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 at 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?