Hi all, I have a problem that''s very similar to this one - which doesn''t appear to have ever been resolved: http://lists.xensource.com/archives/html/xen-users/2007-03/msg00112.html My dom0 will crash when I try to transfer large amounts of files in (e.g. an rsync network backup), when I try to install Windows over HVM (at the beginning of the installer when ''installation files are being put into folders'') and seemingly ''randomly'' throughout the day - although presumably this could be an instance of high I/O on a DomU that I would not be aware of. There are no errors, anywhere that I can see - i''ve checked kern.log/syslog/messages/dmesg/xend.log/xend-debug.log Please; can anyone shed some light on this? At the moment I can lose the machine up to five times a day and obviously can''t install windows or anything! System is running on Ubuntu Hardy, 2.6.24-14 - in case this is a bug with their kernel port i''ve made a bug on launchpad: https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/211751 Has anyone had this before? How did you solve it? Swapping also causes a crash as observed in the initially referenced post, but that''s probably because it''s a high i/o operation. Turning my system''s ability to swap off has helped the problem a little bit (eliminating that point of failure at least) Thanks, Henri _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Henri Cook wrote:> > Hi all, I have a problem that''s very similar to this one - > which doesn''t appear to have ever been resolved: > http://lists.xensource.com/archives/html/xen-users/2007-03/msg00112.html > > My dom0 will crash when I try to transfer large amounts of files in > (e.g. an rsync network backup), when I try to install Windows over HVM > (at the beginning of the installer when ''installation files are being > put into folders'') and seemingly ''randomly'' throughout the day - > although presumably this could be an instance of high I/O on > a DomU that > I would not be aware of. > > There are no errors, anywhere that I can see - i''ve checked > kern.log/syslog/messages/dmesg/xend.log/xend-debug.log > > Please; can anyone shed some light on this? At the moment I > can lose the machine up to five times a day and obviously > can''t install windows or anything! > > System is running on Ubuntu Hardy, 2.6.24-14 - in case this is a bug > with their kernel port i''ve made a bug on launchpad: > https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/211751 > > Has anyone had this before? How did you solve it? > > Swapping also causes a crash as observed in the initially referenced > post, but that''s probably because it''s a high i/o operation. > Turning my system''s ability to swap off has helped the problem a > little bit (eliminating that point of failure at least)Have you tried upgrading your network and storage drivers to the latest versions? Have you performed a ''memtest'' for several passes over your entire memory? IO is memory mapped and a bad byte can cause the server to abend. Have you tried a disk scan? Especially of your swap storage to rule out any bad sectors in swap. Swap doesn''t have the bad sector mapping abilities that file systems have. Try doing all of these and see if it doesn''t fix your problem. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Henri Cook wrote: >> Please; can anyone shed some light on this? At the moment I >> can lose the machine up to five times a day and obviously >> can''t install windows or anything!> Try doing all of these and see if it doesn''t fix your > problem.I think we maybe can limit this to an out of memory? Might be fixable by disabling memory overcommit. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Henri Cook wrote: >> >> Hi all, I have a problem that''s very similar to this one - >> which doesn''t appear to have ever been resolved: >> http://lists.xensource.com/archives/html/xen-users/2007-03/msg00112.html >> >> My dom0 will crash when I try to transfer large amounts of files in >> (e.g. an rsync network backup), when I try to install Windows over HVM >> (at the beginning of the installer when ''installation files are being >> put into folders'') and seemingly ''randomly'' throughout the day - >> although presumably this could be an instance of high I/O on >> a DomU that >> I would not be aware of. >> >> There are no errors, anywhere that I can see - i''ve checked >> kern.log/syslog/messages/dmesg/xend.log/xend-debug.log >> >> Please; can anyone shed some light on this? At the moment I >> can lose the machine up to five times a day and obviously >> can''t install windows or anything! >> >> System is running on Ubuntu Hardy, 2.6.24-14 - in case this is a bug >> with their kernel port i''ve made a bug on launchpad: >> https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/211751 >> >> Has anyone had this before? How did you solve it? >> >> Swapping also causes a crash as observed in the initially referenced >> post, but that''s probably because it''s a high i/o operation. >> Turning my system''s ability to swap off has helped the problem a >> little bit (eliminating that point of failure at least) > > Have you tried upgrading your network and storage drivers to > the latest versions? > > Have you performed a ''memtest'' for several passes over your > entire memory? IO is memory mapped and a bad byte can cause > the server to abend. > > Have you tried a disk scan? Especially of your swap storage > to rule out any bad sectors in swap. Swap doesn''t have the > bad sector mapping abilities that file systems have. > > Try doing all of these and see if it doesn''t fix your > problem. > > -RossIf possible could you downgrade your kernel to 2.6.18 so that it more closely matches the officially supported Xen 3.2 kernel? You are at the bleeding edge with the kernel you''re using and to see if it is a problem with Xen 3.2 or that version of the Kernel with Xen a downgrade would be helpful. Ryan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> Henri Cook wrote: >>> Please; can anyone shed some light on this? At the moment I >>> can lose the machine up to five times a day and obviously >>> can''t install windows or anything! > > >> Try doing all of these and see if it doesn''t fix your >> problem. > > > I think we maybe can limit this to an out of memory? Might be fixable by > disabling memory overcommit. > > > StefanUnless there has been a recent radical change to Xen it isn''t possible to overcommit memory like other virtualization systems. Ryan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I upgraded in an effort to correct the problem - it was present on the older kernel as well Henri Ryan Burke wrote:>> Henri Cook wrote: >> >>> Hi all, I have a problem that''s very similar to this one - >>> which doesn''t appear to have ever been resolved: >>> http://lists.xensource.com/archives/html/xen-users/2007-03/msg00112.html >>> >>> My dom0 will crash when I try to transfer large amounts of files in >>> (e.g. an rsync network backup), when I try to install Windows over HVM >>> (at the beginning of the installer when ''installation files are being >>> put into folders'') and seemingly ''randomly'' throughout the day - >>> although presumably this could be an instance of high I/O on >>> a DomU that >>> I would not be aware of. >>> >>> There are no errors, anywhere that I can see - i''ve checked >>> kern.log/syslog/messages/dmesg/xend.log/xend-debug.log >>> >>> Please; can anyone shed some light on this? At the moment I >>> can lose the machine up to five times a day and obviously >>> can''t install windows or anything! >>> >>> System is running on Ubuntu Hardy, 2.6.24-14 - in case this is a bug >>> with their kernel port i''ve made a bug on launchpad: >>> https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/211751 >>> >>> Has anyone had this before? How did you solve it? >>> >>> Swapping also causes a crash as observed in the initially referenced >>> post, but that''s probably because it''s a high i/o operation. >>> Turning my system''s ability to swap off has helped the problem a >>> little bit (eliminating that point of failure at least) >>> >> Have you tried upgrading your network and storage drivers to >> the latest versions? >> >> Have you performed a ''memtest'' for several passes over your >> entire memory? IO is memory mapped and a bad byte can cause >> the server to abend. >> >> Have you tried a disk scan? Especially of your swap storage >> to rule out any bad sectors in swap. Swap doesn''t have the >> bad sector mapping abilities that file systems have. >> >> Try doing all of these and see if it doesn''t fix your >> problem. >> >> -Ross >> > > If possible could you downgrade your kernel to 2.6.18 so that it more > closely matches the officially supported Xen 3.2 kernel? You are at the > bleeding edge with the kernel you''re using and to see if it is a problem > with Xen 3.2 or that version of the Kernel with Xen a downgrade would be > helpful. > > Ryan > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ryan Burke wrote:> > >> Henri Cook wrote: > >>> Please; can anyone shed some light on this? At the moment I > >>> can lose the machine up to five times a day and obviously > >>> can''t install windows or anything! > > > > > >> Try doing all of these and see if it doesn''t fix your > >> problem. > > > > > > I think we maybe can limit this to an out of memory? Might be fixable by > > disabling memory overcommit. > > > > > > Stefan > > Unless there has been a recent radical change to Xen it isn''t possible to > overcommit memory like other virtualization systems.No, but there is a possibility that the OP under committed dom0. Also make sure that (dom0-min-mem XXX) is set to a reasonable level, 256 with no X, 512 with X, this is found in /etc/xen/xend-config.sxp. -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Yep, dom0 has 512 min-mem - I don''t think it''s a too much memory issue, i''ve had the system die with ~3GB available. I''ll see if I can run a memtest but the machine''s in a DC! I might give KVM a bash - that seems to be what the cool kids are doing these days H Ross S. W. Walker wrote:> Ryan Burke wrote: > >>>> Henri Cook wrote: >>>> >>>>> Please; can anyone shed some light on this? At the moment I >>>>> can lose the machine up to five times a day and obviously >>>>> can''t install windows or anything! >>>>> >>> >>>> Try doing all of these and see if it doesn''t fix your >>>> problem. >>>> >>> I think we maybe can limit this to an out of memory? Might be fixable by >>> disabling memory overcommit. >>> >>> >>> Stefan >>> >> Unless there has been a recent radical change to Xen it isn''t possible to >> overcommit memory like other virtualization systems. >> > > No, but there is a possibility that the OP under committed dom0. > > Also make sure that (dom0-min-mem XXX) is set to a reasonable level, > 256 with no X, 512 with X, this is found in /etc/xen/xend-config.sxp. > > -Ross > > ______________________________________________________________________ > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended recipient > of this e-mail, you are hereby notified that any dissemination, > distribution or copying of this e-mail, and any attachments thereto, > is strictly prohibited. If you have received this e-mail in error, > please immediately notify the sender and permanently delete the > original and any copy or printout thereof. > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Unless there has been a recent radical change to Xen it isn''t possibleto overcommit memory like other virtualization systems. Trust me; this is totally unrelated to Xen and NFS problems were already causing this on 3.1. Reproducable with: Loopback file on NFS. Twice the size as the host ram. Now run bonnie++. In a VM. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Stefan de Konink wrote:> > Unless there has been a recent radical change to Xen it isn''t possible > to overcommit memory like other virtualization systems. > > Trust me; this is totally unrelated to Xen and NFS problems were already > causing this on 3.1. > > > Reproducable with: > Loopback file on NFS. Twice the size as the host ram. > Now run bonnie++. In a VM.So, what are you saying? What are you recommending? Is there a bug filed somewhere that might apply here? -Ross ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Stefan de Konink wrote: >> > Unless there has been a recent radical change to Xen it isn''t possible >> to overcommit memory like other virtualization systems. >> >> Trust me; this is totally unrelated to Xen and NFS problems were already >> causing this on 3.1. >> >> >> Reproducable with: >> Loopback file on NFS. Twice the size as the host ram. >> Now run bonnie++. In a VM. > > So, what are you saying? What are you recommending? Is there a bug > filed somewhere that might apply here?I have mentioned it on xen-devel, and probably on bugzilla. And is one of the reasons to use iSCSI over NFS. Someone told me that it could be fixed by setting the memory overcommit for Linux to ''do not do it''. That is some setting in /etc/sysctl.conf Stefan ps. remove the annoying signature _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I might be jinxing it by saying it - but I think that line in sysctl.conf has done it! The system always crashed previously when i was about 60% through the installation file setup for WinXP - i''ve done that again and admittedly the installer''s not working properly (gets stuck at that 60% mark and qemu-dm on dom0 takes up 110% of cpu (4 cpus)) but importantly DOM0 HASN''T CRASHED! I''m going to try some other operations that crash it regularly like creating new blank images with dd, i might even re-enable swap! Thanks! (Hopefully!) Henri Stefan de Konink wrote:>> Stefan de Konink wrote: >> >>>> Unless there has been a recent radical change to Xen it isn''t possible >>>> >>> to overcommit memory like other virtualization systems. >>> >>> Trust me; this is totally unrelated to Xen and NFS problems were already >>> causing this on 3.1. >>> >>> >>> Reproducable with: >>> Loopback file on NFS. Twice the size as the host ram. >>> Now run bonnie++. In a VM. >>> >> So, what are you saying? What are you recommending? Is there a bug >> filed somewhere that might apply here? >> > > I have mentioned it on xen-devel, and probably on bugzilla. And is one of > the reasons to use iSCSI over NFS. Someone told me that it could be fixed > by setting the memory overcommit for Linux to ''do not do it''. That is some > setting in /etc/sysctl.conf > > > Stefan > > ps. remove the annoying signature > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Looked hopeful for a while but unfortunately that has not fixed the issue, thanks anyway. Henri Henri Cook wrote:> I might be jinxing it by saying it - but I think that line in > sysctl.conf has done it! > > The system always crashed previously when i was about 60% through the > installation file setup for WinXP - i''ve done that again and admittedly > the installer''s not working properly (gets stuck at that 60% mark and > qemu-dm on dom0 takes up 110% of cpu (4 cpus)) but importantly DOM0 > HASN''T CRASHED! > > I''m going to try some other operations that crash it regularly like > creating new blank images with dd, i might even re-enable swap! > > Thanks! (Hopefully!) > > Henri > > > Stefan de Konink wrote: > >>> Stefan de Konink wrote: >>> >>> >>>>> Unless there has been a recent radical change to Xen it isn''t possible >>>>> >>>>> >>>> to overcommit memory like other virtualization systems. >>>> >>>> Trust me; this is totally unrelated to Xen and NFS problems were already >>>> causing this on 3.1. >>>> >>>> >>>> Reproducable with: >>>> Loopback file on NFS. Twice the size as the host ram. >>>> Now run bonnie++. In a VM. >>>> >>>> >>> So, what are you saying? What are you recommending? Is there a bug >>> filed somewhere that might apply here? >>> >>> >> I have mentioned it on xen-devel, and probably on bugzilla. And is one of >> the reasons to use iSCSI over NFS. Someone told me that it could be fixed >> by setting the memory overcommit for Linux to ''do not do it''. That is some >> setting in /etc/sysctl.conf >> >> >> Stefan >> >> ps. remove the annoying signature >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> >> > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I might be jinxing it by saying it - but I think that line in > sysctl.conf has done it! > > The system always crashed previously when i was about 60% through the > installation file setup for WinXP - i''ve done that again and admittedly > the installer''s not working properly (gets stuck at that 60% mark and > qemu-dm on dom0 takes up 110% of cpu (4 cpus)) but importantly DOM0 > HASN''T CRASHED! > > I''m going to try some other operations that crash it regularly like > creating new blank images with dd, i might even re-enable swap! > > Thanks! (Hopefully!) > > Henri > > > Stefan de Konink wrote: >>> Stefan de Konink wrote: >>> >>>>> Unless there has been a recent radical change to Xen it isn''t >>>>> possible >>>>> >>>> to overcommit memory like other virtualization systems. >>>> >>>> Trust me; this is totally unrelated to Xen and NFS problems were >>>> already >>>> causing this on 3.1. >>>> >>>> >>>> Reproducable with: >>>> Loopback file on NFS. Twice the size as the host ram. >>>> Now run bonnie++. In a VM. >>>> >>> So, what are you saying? What are you recommending? Is there a bug >>> filed somewhere that might apply here? >>> >> >> I have mentioned it on xen-devel, and probably on bugzilla. And is one >> of >> the reasons to use iSCSI over NFS. Someone told me that it could be >> fixed >> by setting the memory overcommit for Linux to ''do not do it''. That is >> some >> setting in /etc/sysctl.conf >> >> >> Stefan >>Mind telling the list what the changes you made were? Please let us know if it fixed your problem as you continue your testing. Ryan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I upgraded in an effort to correct the problem - it was present on the > older kernel as wellThe older kernel being the XenSource XenLinux 2.6.18 kernel? The reason this question gets asked by folks is that a 2.6.24 port of full Xen functionality is a long way removed from the upstream XenSource 2.6.18 and it''s potentially possible (with all due respect to distro maintainers) that porting the patches forward 6 kernel releases may have introduced some interesting new bugs. Cheers, Mark> Henri > > Ryan Burke wrote: > >> Henri Cook wrote: > >>> Hi all, I have a problem that''s very similar to this one - > >>> which doesn''t appear to have ever been resolved: > >>> http://lists.xensource.com/archives/html/xen-users/2007-03/msg00112.htm > >>>l > >>> > >>> My dom0 will crash when I try to transfer large amounts of files in > >>> (e.g. an rsync network backup), when I try to install Windows over HVM > >>> (at the beginning of the installer when ''installation files are being > >>> put into folders'') and seemingly ''randomly'' throughout the day - > >>> although presumably this could be an instance of high I/O on > >>> a DomU that > >>> I would not be aware of. > >>> > >>> There are no errors, anywhere that I can see - i''ve checked > >>> kern.log/syslog/messages/dmesg/xend.log/xend-debug.log > >>> > >>> Please; can anyone shed some light on this? At the moment I > >>> can lose the machine up to five times a day and obviously > >>> can''t install windows or anything! > >>> > >>> System is running on Ubuntu Hardy, 2.6.24-14 - in case this is a bug > >>> with their kernel port i''ve made a bug on launchpad: > >>> https://bugs.launchpad.net/ubuntu/+source/xen-3.2/+bug/211751 > >>> > >>> Has anyone had this before? How did you solve it? > >>> > >>> Swapping also causes a crash as observed in the initially referenced > >>> post, but that''s probably because it''s a high i/o operation. > >>> Turning my system''s ability to swap off has helped the problem a > >>> little bit (eliminating that point of failure at least) > >> > >> Have you tried upgrading your network and storage drivers to > >> the latest versions? > >> > >> Have you performed a ''memtest'' for several passes over your > >> entire memory? IO is memory mapped and a bad byte can cause > >> the server to abend. > >> > >> Have you tried a disk scan? Especially of your swap storage > >> to rule out any bad sectors in swap. Swap doesn''t have the > >> bad sector mapping abilities that file systems have. > >> > >> Try doing all of these and see if it doesn''t fix your > >> problem. > >> > >> -Ross > > > > If possible could you downgrade your kernel to 2.6.18 so that it more > > closely matches the officially supported Xen 3.2 kernel? You are at the > > bleeding edge with the kernel you''re using and to see if it is a problem > > with Xen 3.2 or that version of the Kernel with Xen a downgrade would be > > helpful. > > > > Ryan > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users-- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I have mentioned it on xen-devel, and probably on bugzilla. And is one of > the reasons to use iSCSI over NFS. Someone told me that it could be fixed > by setting the memory overcommit for Linux to ''do not do it''. That is some > setting in /etc/sysctl.confHenri, To help people understand what you''re seeing, can you tell us some more about your setup? Is it possible that it''s a problem like this (which may be provoked by such setups as virtual disk files stored on NFS, etc...). It''d be useful to know whether you''d been able to try the upstream XenSource XenLinux (which really ought to work, if anything does - otherwise it''s definitely an upstream XenLinux bug!). Out of interest, where did you source the rest of your Xen 3.2 installation - Ubuntu packages, source tarball from Xensource, or ... ? Also, I gather this machine is in a remote hosting facility somewhere? Is it possible that some kind of kernel panic message is being printed to the display when crashes? Can someone in the datacentre have a look? Better than that would probably be to get a serial line hooked up so that any crash-time output can be captured - even if the system is too far gone to log it to disk. Do you think this might be possible? Cheers, Mark -- Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> I have mentioned it on xen-devel, and probably on bugzilla. And is one >> of >> the reasons to use iSCSI over NFS. Someone told me that it could be >> fixed >> by setting the memory overcommit for Linux to ''do not do it''. That is >> some >> setting in /etc/sysctl.conf > > Henri,I guess you mean me :)> To help people understand what you''re seeing, can you tell us some more > about > your setup? Is it possible that it''s a problem like this (which may be > provoked by such setups as virtual disk files stored on NFS, etc...).Stupid Dell 1950 with 8GB of memory. A NetApp NFS server or if you like a Linux one or if you like an OpenSolaris one. Nothing fancy from that point of view.> It''d be useful to know whether you''d been able to try the upstream > XenSource > XenLinux (which really ought to work, if anything does - otherwise it''s > definitely an upstream XenLinux bug!). Out of interest, where did you > source > the rest of your Xen 3.2 installation - Ubuntu packages, source tarball > from > Xensource, or ... ?This quote you refer to is all based on Gentoo Linux.> Also, I gather this machine is in a remote hosting facility somewhere? Is > it > possible that some kind of kernel panic message is being printed to the > display when crashes? Can someone in the datacentre have a look? Better > than that would probably be to get a serial line hooked up so that any > crash-time output can be captured - even if the system is too far gone to > log > it to disk. Do you think this might be possible?If you tell me how to get a dump of Xen on a machine that is actually crashing I''m happy to assist. Please contact me in private. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users