[ovirt-devel] [vdsm][virt] what's new in virt (20151215)

[Nir Soffer]

On Tue, Dec 15, 2015 at 5:12 PM, Francesco Romani <fromani at redhat.com> wrote:
> Hi all,
>
> I'm happy to start a weekly summary of what's going on on virt's world (VDSM edition).
>
> General topics
> * I've got some mixed feedback about my Vm-on-a-diet effort. I still believe that fat trimming
>   is a worthwhile goal per se, but I'm willing to adapt the strategy responding to the comments,
>   so we will focus on virt-specific topics.
> * As consequence of the above, I'm focusing on the last bits of device fixing, which involves
>   - fixing all device to update themselves from libvirt XML after domain boot, instead using
>     all the getUnderyling* methods

+1

>   - switch the devices related code to use Etree instead of minidom. This will involve changes to
>     the domain_descriptor.
>   I estimate this task will still trim ~600 lines out of vm.py, so it still somehow gets some
>   size trimming done, albeit not intensive as planned.
>   This is a complex topic, will post plan and ideas on a separate mail

+1, lets kill minidom entirely.

> * Finally, some series are still worth pushing forward, see below.
>
> Patches in need of attention
> * topic branches
> - mpolednik started a much needed cleanup and fixing of fake_qemu and fake_kvm code, with the ultimate goal to move all
>   the remaining bits into the faqemu hook, and to make it useful on ppc64.
>   Lots of refactoring is needed to support this change, and that produced
>   https://gerrit.ovirt.org/#/q/topic:cpuinfo

I reviewed the first and biggest patch. I like the idea, but I think
we should make some
small changes before it, for example removing of the POWER constant.

having constats of the same group using different types is a horrible idea.
    X86_64 = "x86_64"
    POWER = ("ppc64", "ppc64le")

Before we do big and risky cleanups, we should do small and safe cleanup like
unifying the constants.

Another issue, there is no point in moving caps.Architecture to
cpuarch.Architecture.
In the caps module, this class used to group the constants like X86_64.
the cpuarch module is replacing the Architecture class, so we would
like one patch moving the constants and eliminating the useless class.

Having too patches, one moving the class and the other eliminating it
is wasting reviewers time.

I'm waiting for more reviews from the virt guys on this topic.

> - we want to improve the reporting in case of migratio aborted. The ultimate goal is to let Engine (thus the User)
>   know why a migration failed.

Why the reason is not available? Maybe this is another use case for the jobs
module? Keep a job for each migration, report job status and errors?

> To export this information, however, we need some cleanup before. Hence:
>   https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:migration_report
> - last and less urgent: here's some cleanup about existing getUnderlying* methods of Vm class, preparing
>   the last step of the big vmdevices split. I believe this is useful anyway
>   https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vm-trim-stage-1-p4-pre
>
> * single patches
> - https://gerrit.ovirt.org/#/c/46846
>   this is the first of a series aiming to improve migration support in 4.0. Probably worth merging all together,
>   even though this one seems ready for broader review to me.
> - https://gerrit.ovirt.org/#/c/49173/
>   Notified just to raise awareness, still working on ensuring backward compatibility and smooth upgrade
> - https://gerrit.ovirt.org/#/c/48672
>   v2v xen support
> - https://gerrit.ovirt.org/#/c/49951/
>   OVA support improvements. Worth a look, but note that we are working toward a split of this big patch
> - https://gerrit.ovirt.org/#/c/49636
>   V2V refactoring, also almost ready

We need more reviewers for the v2v patches.

> - https://gerrit.ovirt.org/#/c/49570/
>   still in the context of migration enhancements. We want to throttle incoming migrations, to do so we want
>   to use a sempahore which needs to be held by the creation thread until VM is created.
>   This helper makes this possible, using an uniform interface for both this case and the common, simpler case.

This code is too abstract, we should have something that is more
about incoming migration, not about running async tasks with resources.

>
> That's all for now, as usual, reviews welcome! :)
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel