> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list