Xen devel - Jul 2009 - throttling logs messages from qemu

I see that in 3.4.x, throttling has been changed from a file in /etc to
a xenstore entry, as per the following code:

    throttling = xenstore_vm_read(domid, "log-throttling", &len);
    if (throttling != NULL) {
        throttling_disabled = (throttling[0] - ''0'');
        free(throttling);
    }

A bit of searching tells me that the full path of the key is
/vm/<uuid>/log-throttling, but it appears to be read at boot. How can I
get it written in there in time?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 31 Jul 2009, James Harper wrote:
> I see that in 3.4.x, throttling has been changed from a file in /etc to
> a xenstore entry, as per the following code:
> 
>     throttling = xenstore_vm_read(domid, "log-throttling",
&len);
>     if (throttling != NULL) {
>         throttling_disabled = (throttling[0] - ''0'');
>         free(throttling);
>     }
> 
> A bit of searching tells me that the full path of the key is
> /vm/<uuid>/log-throttling, but it appears to be read at boot. How can
I
> get it written in there in time?
> 
Good question :)
You could hack xend but it is not exactly something you want to do.
Another possibility is to change your device_model in the vm config file
to a bash script that does what you want and then calls qemu-dm with the
right arguments.
We could probably modify qemu to read the xenstore key from another
place that is easier to know before the VM is started.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On Fri, 31 Jul 2009, James Harper wrote:
> > I see that in 3.4.x, throttling has been changed from a file in /etc
to
> > a xenstore entry, as per the following code:
> >
> >     throttling = xenstore_vm_read(domid, "log-throttling",
&len);
> >     if (throttling != NULL) {
> >         throttling_disabled = (throttling[0] - ''0'');
> >         free(throttling);
> >     }
> >
> > A bit of searching tells me that the full path of the key is
> > /vm/<uuid>/log-throttling, but it appears to be read at boot.
How
can I
> > get it written in there in time?
> >
> 
> Good question :)
> You could hack xend but it is not exactly something you want to do.
> Another possibility is to change your device_model in the vm config
file
> to a bash script that does what you want and then calls qemu-dm with
the
> right arguments.
> We could probably modify qemu to read the xenstore key from another
> place that is easier to know before the VM is started.
Can we revert the patch then? I assume the citrix version of xend puts
the log-throttling key in based on certain criteria but maybe it isn''t
appropriate for the gpl version? I mean it''s pretty much useless in
this
form isn''t it? It worked great for me as detecting the presence of a
file in /etc...

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 1 Aug 2009, James Harper wrote:
> Can we revert the patch then? I assume the citrix version of xend puts
> the log-throttling key in based on certain criteria but maybe it
isn''t
> appropriate for the gpl version? I mean it''s pretty much useless
in this
> form isn''t it? It worked great for me as detecting the presence of
a
> file in /etc...
I think it is important that we try to limit unneeded access from qemu
to the dom0 filesystem: the fs-backend daemon was needed at boot time
for stubdoms only because of the
stat("/etc/disable-guest-log-throttle").
I am sure we can figure out a better alternative that works for
everyone.
For example we could set a watch on xenstore for that node instead of
just reading it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> 
> On Sat, 1 Aug 2009, James Harper wrote:
> > Can we revert the patch then? I assume the citrix version of xend
puts
> > the log-throttling key in based on certain criteria but maybe it
isn''t
> > appropriate for the gpl version? I mean it''s pretty much
useless in
this
> > form isn''t it? It worked great for me as detecting the
presence of a
> > file in /etc...
> 
> I think it is important that we try to limit unneeded access from qemu
> to the dom0 filesystem: the fs-backend daemon was needed at boot time
> for stubdoms only because of the
> stat("/etc/disable-guest-log-throttle").
> I am sure we can figure out a better alternative that works for
> everyone.
> For example we could set a watch on xenstore for that node instead of
> just reading it.
That could work. What about having a per domain config option in the
standard config that ''xm create'' picks up and puts in? That
would be the
most useful to me...

Which would be less work?

When running in a stub domain, where does the logfile go?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 3 Aug 2009, James Harper wrote:
> > 
> > On Sat, 1 Aug 2009, James Harper wrote:
> > > Can we revert the patch then? I assume the citrix version of xend
> puts
> > > the log-throttling key in based on certain criteria but maybe it
> isn''t
> > > appropriate for the gpl version? I mean it''s pretty much
useless in
> this
> > > form isn''t it? It worked great for me as detecting the
presence of a
> > > file in /etc...
> > 
> > I think it is important that we try to limit unneeded access from qemu
> > to the dom0 filesystem: the fs-backend daemon was needed at boot time
> > for stubdoms only because of the
> > stat("/etc/disable-guest-log-throttle").
> > I am sure we can figure out a better alternative that works for
> > everyone.
> > For example we could set a watch on xenstore for that node instead of
> > just reading it.
> 
> That could work. What about having a per domain config option in the
> standard config that ''xm create'' picks up and puts in?
That would be the
> most useful to me...
> 
> Which would be less work?
hacking qemu beats hacking xend anytime for me :)

> When running in a stub domain, where does the logfile go?
same place: /var/log/xen/qemu-dm-$domainname.log, besides that you also have
/var/log/xen/qemu-dm-$domainname-dm.log that contains the pv qemu logs
(the logs from the qemu process that runs in dom0 to provide the pv
 framebuffer backend to the stubdom)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel