[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] autostart with xend

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.

|: 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 :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]