1:10 p.m.
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.
Suggestions?
Also, why isn't this represented in the XML?
thanks,
john
5:56 a.m.
On Fri, Jan 30, 2009 at 02:10:57PM -0500, John Levon 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.
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).
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:09 a.m.
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
12:03 p.m.
On Thu, Feb 05, 2009 at 12:09:16PM -0500, John Levon wrote:
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:
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.
You should be able to see it with 'virsh dominfo'
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.
I think XenD should have the new config in memory still, but it won't
be visible until you stop the currently active VM. I don't know of any
other way to address this either, except perhaps switch to XenAPI so
we can update individual fields, instead of having the re-define the
whole VM.
> > 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?
We didn't consider autostart to be configuring the guest VM itself, but
rather be a policy/tunable setting relating to control of the VM. And
it was treated this way in XenD too...until it was added to the SEXPR.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
12:50 p.m.
On Thu, Feb 05, 2009 at 06:03:48PM +0000, Daniel P. Berrange wrote:
> Python API, you can see it returning False when it
shouldn't.
You should be able to see it with 'virsh dominfo'
Yes, sorry. You do indeed see the wrong answer there.
> 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.
I think XenD should have the new config in memory still, but it won't
be visible until you stop the currently active VM.
That's right.
I don't know of any
other way to address this either, except perhaps switch to XenAPI so
we can update individual fields, instead of having the re-define the
whole VM.
OK. Darn :)
regards
john
5801
days inactive
5807
days old
4 comments
2 participants
participants (2)
-
Daniel P. Berrange -
John Levon