On Thu, Feb 05, 2009 at 11:56:59AM +0000, Daniel P. Berrange wrote:
> It doesn't work quite right with a running domain. The
'new' will
> correctly set the config, but the temporary config doesn't include the
> new setting. So tests of the form "set autostart; is it set?" will fail.
I'm not sure I understand the sequence of operations you're describing
here - can you illustrate with virsh example.
Sure:
# xm list -l domu-220 | grep on_xend_start
(on_xend_start ignore)
# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # autostart domu-220
Domain domu-220 marked as autostarted
# xm list -l domu-220 | grep on_xend_start
(on_xend_start start)
virsh # autostart domu-220 --disable
Domain domu-220 unmarked as autostarted
# xm list -l domu-220 | grep on_xend_start
(on_xend_start ignore)
virsh # start domu-220
Domain domu-220 started
virsh # autostart domu-220
Domain domu-220 marked as autostarted
# xm list -l domu-220 | grep on_xend_start
(on_xend_start ignore)
# grep on_xend_start /var/lib/xend/domains/`virsh domuuid domu-220`/config.sxp
(on_xend_start start)
There's no direct virsh command to display autostart, but if you use the
Python API, you can see it returning False when it shouldn't.
The problem is that we're doing a "new" and xend is routing that through
to the static config only. I'm not sure if there's actually a better
solution, though.
> Also, why isn't this represented in the XML?
Bear in mind there's 2 impls of this. For older XM, we are just creating
and deleting symlinks in /etc/xen/autostart, only in newer XM are we
having to update the SXPR (which is harder).
Sorry, I'm being dense: why does this affect it not being in XML? Was it
just an oversight with the original /etc/xen implementation, or
something else?
regards,
john