[libvirt] [PATCH 2/2] qemu: extend logging to record guest configuration events

[Naoya Horiguchi]

Hi,

On Mon, Apr 04, 2011 at 03:55:26PM +0100, Daniel P. Berrange wrote:
> On Mon, Mar 28, 2011 at 05:13:47PM +0900, Naoya Horiguchi wrote:
> > The following events can be logged onto /var/log/libvirt/qemu/<domain>.log:
> >
> >   starting/shutting down/suspending/resuming/migrating domains
> >   changing the amount of memory
> >   changing the number of VCPUs
> >   inserting/ejecting a media into/from CDROM/Floppy devices
> >   attaching/detaching PCI/SCSI/USB devices (including NICs and disks.)
> >
> > This patch generalizes qemudLog*() introduced in commit 93bc093ac
> > to handle the whole range of qemu driver's events.
> >
> > This is useful for the same reason as explainged in the previous patch.
>
> I think we need to think about the question of logging
> in a more thorough way.
>
>  - libvirt.c: Logs invocation of every API call
>  - qemu/driver.c/qemu_audit.c: Logs major lifecycle changes &
>    any config change that is related host resources
>  - virterror.c: Logs any API call that results in an error
>  - qemu_driver.c: Logs a set of lifecycle/config changes
>    (your previous patch 1/2) at VIR_INFO
>  - qemu_driver.c: Logs a different set of lifecycle/config
>    changes in /var/log/libvirt/qemu/<domain>.loog

Thank you for detailed explanation.

> I don't think the latter two are particularly great because
> they are only cover a fraction of the API calls in the QEMU
> driver. libvirt.c has full logging cover, but it only covers
> API calls, it doesn't indicate whether it was successful or
> failed.

I see.

> For SystemTAP, we likely want to add probes to libvirt.c
> which will log initial parameters, and the return values.
> Our SystemTAP probe macros also generate log statements.
>
> A further complication is that /var/log/libvirt/qemu/$NAME.log
> is intended for QEMU's  stderr output. The only time that
> libvirtd currently writes to it, is before QEMU starts and after
> it has shutdown.

OK.

> This new patch means that libvirtd writes to it while QEMU is
> running, which is not really safe because you can now end up
> with 2 proceses writing to the same file at once. The log
> messages may well get interleaved/corrupted by each other.
> I don't think that is good for something that wants to be
> used as a formal record of operations on a VM.
>
> I think that in each driver we only really want to have to
> insert one set of formal "operation logging" calls. Since
> we already have the audit APIs present, I think we could try
> to make use of that to generate a record of operations against
> a VM in some way.

I didn't care about audit logging because it's not used in RHEL6.0.
I tried this logging mechanism and made sure that this logging recorded
enough information about operational events in /var/log/libvirt/libvirtd.log.
This feature meets our demand, so I'll drop this patch.

Thanks,
Naoya