Comment 22 for bug 832507

Daniel Berrange (berrange) wrote :

> > The reason for the qemu-kvm task is that we think qemu-kvm is really the ultimate right place to add a '-serial ringbuffer:640k,file=/path/to/file' flag.
> > All the other attempts are more hacky, but if upstream kvm had this , libvirt could expose it, and openstack could use it.
> > I do not know whether or not it would be accepted upstream.

This is an interesting idea & worth proposing to QEMU upstream to see what their feelings are on this - with this kind of concept, their reaction can be quite unpredictable, so I can't say more than a 50/50 chance they'll go for it. The reason I think they might not go for it, is that it implements just one out of many potential different policies. eg, a viable alternative would be to rotate log files periodically instead of using a ring buffer.

If KVM doesn't care todo this, from a libvirt POV, I have long imagined the need for a "libvirt_vmlogd" daemon which would run independently of libvirtd or QEMU. The QEMU guests would be configured with either a PTY or more likely a UNIX socket (eg '-serial unix:/var/lib/libvirt/qemu/serial0.socket'). The libvirt_vmlogd would automatically connect to the sockets as each guest was launched, and log the data according to some policy it is configured with, and handle log rotation / expiration etc.

For the sake of the Nova security issue, I think it'd be wise to implement a fix in Nova regardless, since both the upstream approaches could take some time.