From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Some VMs are crashed in xen 4.0.1 Date: Fri, 25 Feb 2011 08:00:22 +0000 Message-ID: References: <43FEA041821E5247942BF0802912D93803DC0FB3@ADCEXMAIL03.tw.trendnet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <43FEA041821E5247942BF0802912D93803DC0FB3@ADCEXMAIL03.tw.trendnet.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: wenche_chang@trend.com.tw, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 25/02/2011 02:37, "wenche_chang@trend.com.tw" wrote: > We Run 150 Fedora13 VMs on many hypervisor , images and xml are stored in= DFS. > =20 > Some of the VMs will be crashed in 48 hours. Some of the VMs will remain. > (The VMs have some IO/CPU loading by start up a loading services.) >=20 > All the crashed VM has the same WARNING message in xend.log, for example: > [2011-02-18 10:42:36 3235] WARNING (image:552) domain > 5ab73a3f-87da-48fd-9236-a2f752c16c76: device model failure: pid 11037: di= ed > due to signal 11; see > /var/log/xen/qemu-dm-5ab73a3f-87da-48fd-9236-a2f752c16c76.log Your qemu-dm processes are dying on SIGSEGV. You need to get a core dump from one of these crashed processes and use gdb to get a backtrace. -- Keir > The qemu-dm log is like this > =20 > /var/log/xen/qemu-dm-1cf74c71-62c2-4411-abb2-1db0a2e45142.log > domid: 35 > config qemu network with xen bridge for tap35.0 teprod > Using file=20 > /mnt/vm_depot/volume_pool/fd3e/47/fd3e4783-9c66-4313-b51a-8b737a792392 in > read-write mode > Watching /local/domain/0/device-model/35/logdirty/cmd > Watching /local/domain/0/device-model/35/command > char device redirected to /dev/pts/2 > qemu_map_cache_init nr_buckets =3D 10000 size 4194304 > shared page at pfn feffd > buffered io page at pfn feffb > Guest uuid =3D 1cf74c71-62c2-4411-abb2-1db0a2e45142 > Time offset set 0 > populating video RAM at ff000000 > mapping video RAM from ff000000 > Register xen platform. > Done register platform. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw > state. > xs_read(/local/domain/0/device-model/35/xen_extended_power_mgmt): read er= ror > xs_read(): vncpasswd get error. > /vm/1cf74c71-62c2-4411-abb2-1db0a2e45142/vncpasswd. > Log-dirty: no command yet. > I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 > xs_read(/local/domain/35/log-throttling): read error > qemu: ignoring not-understood drive `/local/domain/35/log-throttling' > medium change watch on `/local/domain/35/log-throttling' - unknown device= , > ignored > cirrus vga map change while on lfb mode > mapping vram to f0000000 - f0400000 > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw > state. > platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro > state. > =20 > =20 > =20 > I found a mail last year in > http://xen.1045712.n5.nabble.com/PATCH-0-2-Fix-could-not-boot-vm-image-wh= ich-c > onverted-from-phy-partition-td2548812.html > , but it=B9s XEN 3.4.0, and we use XEN 4.0.1 RELEASE. > =20 > It=B9s a bug of XEN or something else? > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidenti= al > and may be subject to copyright or other intellectual property protection= . If > you are not the intended recipient, you are not authorized to use or disc= lose > this information, and we request that you notify us by reply mail or tele= phone > and delete the original message from your mail system. >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel