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

Re: [Xen-devel] Domain status after shutdown command: ---s--


  • To: Dominik Klein <dk@xxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Wed, 09 Apr 2008 15:39:23 +0100
  • Delivery-date: Wed, 09 Apr 2008 07:49:10 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AciaT4COvybTEQZCEd2S9QAX8io7RQ==
  • Thread-topic: [Xen-devel] Domain status after shutdown command: ---s--

What's in the tail of /var/log/xen/xend.log after the domain shuts down?

 -- Keir

On 9/4/08 15:25, "Dominik Klein" <dk@xxxxxxxxxxxxxxxx> wrote:

> So I'm not alone with that problem.
> 
> I just tested with 3.2.1rc3 and the problem persists.
> 
> Regards
> Dominik
> 
> Marc Patino Gómez wrote:
>> Hi all,
>> 
>> I have the same problem, I'm using also Debian Etch on AMD64 and Xen
>> 3.2.0 builded from sources. At the moment, I am trying to find a
>> solution for this issue.
>> 
>> Regards,
>> 
>> Marc
>> 
>> Dominik Klein wrote:
>>> Hi
>>> 
>>> this was already on xen-users, but noone could help.
>>> 
>>> I use Xen 3.2 on debian etch, build from source. domU is also debian
>>> etch.
>>> 
>>> I can create the domain just fine, but when I shut it down, it stays
>>> in status "---s--" forever until I use "xm destroy".
>>> 
>>> At first, I put domU on a DRBD disk with the block-drbd script, but I
>>> also tried with a file-backed domU, which results in the same problem.
>>> 
>>> The logs do not show any errors. Or at least I cannot see anything
>>> that looks like an error.
>>> 
>>> Here's what I see if I shutdown the domain from a console:
>>> 
>>> debian dktestvmxen:~# halt
>>> Broadcast message from root@dktestvmxen (tty1) (Mon Feb 11 08:32:34
>>> 2008):
>>> The system is going down for system halt NOW!
>>> INIT: Switching to runlevel: 0
>>> INIT: Sending processes the TERM signal
>>> Stopping periodic command scheduler: crond.
>>> Stopping internet superserver: inetd.
>>> Stopping OpenBSD Secure Shell server: sshd.
>>> Stopping kernel log daemon: klogd.
>>> Stopping system log daemon: syslogd.
>>> Asking all remaining processes to terminate...done.
>>> Killing all remaining processes...done.
>>> Deconfiguring network interfaces...done.
>>> Cleaning up ifupdown....
>>> Deactivating swap...done.
>>> Will now halt.
>>> md: stopping all md devices.
>>> xenbus_dev_shutdown: device/console/0: Initialising != Connected,
>>> skipping
>>> System halted.
>>> 
>>> At this point, the console is locked. If I quit the console with
>>> CTRL+5 and use "xm list", I see
>>> 
>>> # xm list
>>> Name                                        ID   Mem VCPUs      State
>>> Time(s)
>>> Domain-0                                     0   256     1     r-----
>>> 37627.4
>>> dktestvmxen                                  1   256     1
>>> ---s--    4.8
>>> 
>>> Here's my domU config file:
>>> 
>>> kernel='/boot/vmlinuz-2.6.18.8-xen'
>>> ramdisk='/boot/initrd-2.6.18.8-xen.img'
>>> disk = [ 'file:/dktestvmxen.img,hda1,w' ]
>>> memory = 256
>>> maxmem = 512
>>> builder = 'linux'
>>> name = 'dktestvmxen'
>>> vif = [ 'mac=00:16:3e:13:71:7b,bridge=eth1' ]
>>> localtime = 0
>>> on_poweroff = 'destroy'
>>> on_reboot = 'restart'
>>> on_crash = 'restart'
>>> root = '/dev/hda1'
>>> extra='TERM=xterm xencons=tty console=tty1'
>>> 
>>> This also happens if I shutdown the domain with "shutdown -hP now" or
>>> "xm shutdown $domid" from dom0.
>>> 
>>> Any help would be much appreciated.
>>> 
>>> Regards
>>> Dominik
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.