I apologize about that list etiquette breach. Was completely unaware a thread string was attached somewhere. Never knew that. I will observe that courtesy. I will go through yours and Christopher's points after I get some needed other work done. After that, I may just backup the domUs I developed and do a new install. I must have hosed something. Eric Searcy wrote: > 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 ;-) > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt >