On Mon, Nov 30, 2009 at 11:18 AM, Ben M. <centos@xxxxxxxxxx> 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@river22 ~]# service xendomains start > Starting auto Xen domains: v22c54[done] [ OK ] > [root@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@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@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@river22 ~]# xm list > Name ID Mem(MiB) VCPUs State Time(s) > Domain-0 0 1024 2 r----- 29.7 > [root@river22 ~]# xm shutdown v22c54 > Error: Domain 'v22c54' does not exist. > Usage: xm shutdown <Domain> [-waRH] > > Shutdown a domain. > [root@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 ;-) _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
