Arik Hadas <[email protected]> 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 <[email protected]> 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? _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
