Re: [libvirt] Draft of pre migration checks framework
First, thanks for the efforts (sometimes, as open source developers,
we
get too caught up in our own work, and forget to acknowledge the work of
others; at which point our reviews come across as overly-critical, even
though that is not the intent).
Thank you for the fast answer! I preferred to learn the hook mechanism
before to send you my reply.
Rather than sending lots of attachments, one per file, it would be
nicer
to send one commit (if this is all atomic) or a series of commit files
(incremental atomic changes), and preferably inline to make it easier to
respond to files in email. 'git send-email' can be quite handy in this
regards.
The file HACKING has some more tips for submitting patches that are
easier to review.
Ok! I will bear in mind for the next patch.... ;-)
... I'm still not sure
you've done a good job of saying _why_ we need it, and how it solves
problems not already solvable with the hooks mechanism.
This requires recompilation, whereas the hooks mechanism allows addition
of a new hook via editing an external file with no recompilation. I'm
still wondering why a builtin mechanism is more extensible than
something that uses an external file.
I started my work before the introducion of hooks, and for this reason I
didn't consider them as a possible developing way. Besides the core of
my work is the "security" of migration process, and for this reason I
think that a built-in solution application is better then one external.
I've a second version of my code wich uses shared objects and the
function ldopen(). In this way only one libvirt code recompilation is
required: just to add a ldopen() support. All checks are implemented as
shared objects in external file. So the code previously posted
can be used as hook-like mechanism.
To respect the libvirt-guidelines I've also implemented a third version
of my code. It's a draft implementation of "qemu driver hook".
Before sending the patch I would prefer to discuss with you my hook
design.
I supposed that my hook recives from libvirt the parameters listed
below:
object: name of domain to migrate
operation: migrate
suboperation: pmc (this enable pre migration checks)
extra: destination uri
The hook is called during migration process in particular in function
qemudDomainMigratePerform() - /src/qemu/qemu_driver.c
Hook performs some checks listed in libvirt site
http://wiki.libvirt.org/page/TodoPreMigrationChecks
moreover, I defiend a simple check (not listed in libvirt site) that
uses Trusted Platform Module (TPM) measurations (quote). This is the
real core of my work!
Now I'm try to convince you that my work is a "what you need"! :-D
Immagine the scenario: we have to migrate a VM to another remote host.
This VM hosts a database whose data are privates (like bank account
data). As well as to ckeck the libvirt compatibility (capabilities,
network configuration, ...) we need to check also the "security" of the
remote host. We can perform this check by using Trusted Platform
Module (TPM) measurations. For example, we can compare a "good quote" of
remote host stored on local host, with quote recived by remote host
during the check.
Here a simple graph that represent tpm check phases:
http://pastebin.com/qG6GUXBa
In this way we are sure that the remote and local host are equals both
libirt-compatibility-side and security-side!
Did I convince you? I hope your answer is "Yes!" ;-)
What about my hook design?
Any suggetstions | criticisms |questions | swearwords are appreciated?
Caveat - I have not glanced at any of your patch files, neither for
style reviews nor for algorithmic review.
Mmmm....for this reason I don't send you invitation for my saturday
party! ;-)
--
PAOLO SMIRAGLIA
http://portale.isf.polito.it/paolo-smiraglia