5:23 a.m.
On Tue, Dec 15, 2015 at 5:12 PM, Francesco Romani <fromani(a)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...
- 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...
* 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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel