[CentOS-virt] xendomains not autostarting

On Mon, Nov 30, 2009 at 11:18 AM, Ben M. <centos at rivint.com> wrote:
> Thanks, you gave me some solid points to check that I hadn't fully and I
> think I know a little more.
>
> My chkconfig run level 2 was on, but runlevel was at "N 3". I toggled
> off, rebooted, no difference. Toggled on and off for the rest of the
> checklist.

(p.s. on next most recent post: it's not about the "list", it's that
your email client contains a reference to the thread which other mail
clients use to present the thread in some manner--a tree or such.
"All other lists you have been on" would have acted the same way, you
just may not have realized as we all have different email clients.)

I didn't go into detail about what I was trying to point out about the
runlevels, which I think may have led you astray a bit.  Being in
runlevel 3 means it wouldn't matter whether xendomains is set to start
when in 2.  I only brought it up because by default xendomains doesn't
start in 2, so *if* you were starting in 2 it wouldn't start then.  As
you're apparently running in 3 (the default), "toggling" the setting
for 2 was a bit of a red herring.

> Everything checked out except for XENDOMAINS_RESTORE=true
> which is default. I set it to false, toggled the runlevel 2 for a couple
> of reboot checks. No joy, but ...
>
> Oddly I am getting Saves, even though DESTROY is explicitly set in the
> vm's conf to all circumstances:

"destroy" in this context is your setting for what happens when the
domain stops *on its own accord*.  You still get saves if you shut
down the dom0 and the xendomains script goes around and saves all the
running domains (assuming it is configured to do that).

> name = 'v22c54'
> uuid = 'a3199faf-edb4-42e5-bea1-01f2df77a47f'
> maxmem = 512
> memory = 512
> vcpus = 1
> bootloader = '/usr/bin/pygrub'
> on_poweroff = 'destroy'
> on_reboot = 'destroy'
> on_crash = 'destroy'
> vfb = [ 'type=vnc,vncunused=1,keymap=en-us' ]
> # note selinux is off now, but the privileges are set correctly
> disk = [ 'tap:aio:/var/lib/xen/images/vms/v22c54,xvda,w' ]
> vif = [ 'mac=00:16:36:41:76:ae,bridge=xenbr1' ]
>
> I then slapped it around a bit and another quirk appeared.
>
>  From a fresh boot, I then manually started xendomains service. v22c54
> comes up. I did an xm shut and it reported it shut, nothing in the Save
> folder. However, check this out:
>
> [root at river22 ~]# service xendomains start
> Starting auto Xen domains: v22c54[done]                    [  OK  ]
> [root at river22 ~]# xm list
> Name                             ID Mem(MiB) VCPUs State   Time(s)
> Domain-0                          0     1024     2 r-----     24.7
> v22c54                            1      511     1 r-----      9.0
>
> [root at river22 ~]# xm shutdown v22c54
> (no echo)
>
> (I then tried to bring it back up, it balks, its not there and I see a
> boot_kernel.random and a boot_ramdisk.random come up in /var/lib/xen)
>
> [root at river22 ~]# xm create v22c54
> Using config file "/etc/xen/v22c54".
> Error: VM name 'v22c54' already in use by domain 1
>
> (it isn't there)
> [root at river22 ~]# xm list
> Name                             ID Mem(MiB) VCPUs State   Time(s)
> Domain-0                          0     1024     2 r-----     29.7
> [root at river22 ~]# xm shutdown v22c54
> Error: Domain 'v22c54' does not exist.
> Usage: xm shutdown <Domain> [-waRH]
>
> Shutdown a domain.
> [root at river22 ~]# xm list
> Name                                      ID Mem(MiB) VCPUs State   Time(s)
> Domain-0                                   0     1024     2 r-----     29.9
>
> I certainly like to know why things glitch and don't mind seeing this
> through a little further, but I am beginning to wonder if I should just
> backup the domU's and try a fresh installation.
>
> Is it possible I am running into a naming convention on these domUs?
>
> My first 3 chars help me determine on which host the virtual machine was
> originally created.

Likely just a timing issue if that was the order you ran the commands
in.  xm shutdown tells the guest to shutdown, it doesn't instantly
destroy it.  This can take awhile dependent on what your guest needs
to do.  If xm create told you it was still in use, it probably was
still shutting down.  It then probably finished shutting down and was
gone when you ran xm list.  The only thing that would be alarming is
if you ran xm list *first* and didn't see the domain and then ran xm
create and it told you it was in use.

Typically if I need to hard-cycle the host (config file changes) I
shut down a guest from the guest OS, watch xm list until it goes away,
and then run xm create.

The other thing I meant to suggest in my first email would be
modifying (make a backup first) the xendomains start() function to
append `date` to some random file in /tmp or similar.  That would help
target whether the error is that the xendomains script isn't running
(OS configuration issue) or that it is running but not starting the
domain (something more to do with xen configuration).

Anyways, these are just some general "what steps would I take to
investigate this error"; I disclaim any warranty from whether these
might lead you on a wild goose chase if you run too far with them ;-)