Hi,
I have a server with Supermicro X7DVL-3 (P9) motherboard, 16G ECC RAM and
LSI SAS 1068e RAID controller. I installed CentOS 6.5 64bit on the machine
without any problems, but after following the Xen setup steps at
http://wiki.centos.org/HowTos/Xen/Xen4QuickStart
which installed me the kernel 3.10.32-11.el6.centos.alt.x86_64, I
encountered a problem: After "Starting certmonger [OK]" the screen went
black and the system became unresponsive: keyboard was not working (NumLock
did not respond) and SSH was not responding either. After first lockup I
increased dom0 max mem to 2G, but rebooting after that produced the same
result. The strange thing is, that after a third reboot everything worked
ok: screen went black for a moment after "Staring certmonger [OK]" but
after that the graphical login screen appeared and I could use the system
normally. The fourth reboot went ok as well.
Any ideas what could cause this kind of behaviour?
Regards,
Peter
Subject: Re: [CentOS-virt] Xen4CentOS kernel panic on dom0 reboot
On Wed, Mar 5, 2014 at 10:17 AM, David Vrabel <david.vrabel at citrix.com>wrote:
> > On 05/03/14 15:09, Karl Johnson wrote:
> > > I've been using Xen4CentOS for the last 3 months. It's working fine and
> > > dom0/domUs are stable but the server does a kernel panic when doing a
> > > reboot and the server has to be hard reset manually. It has kernel panic
> > on the 3 last reboot.
> >
> > There is a xenbus device still present and during shutdown it is trying
> > to set it to CLOSED but at this point xenstored isn't running and the
> > xenbus write stalls.
> >
> > Do you have VMs that are still running when you attempt a reboot? If so
> > shutting them down will likely avoid this.
> >
> > Can you provide the output of xenstore-ls prior to attempting a reboot?
> >
> >
> >
> I though Xen init.d scripts would stop all of them before rebooting? Here's
> the output of chkconfig and xenstore-ls:
>
> http://pastebin.centos.org/8186/
>
> Thanks,
>
> Karl
I've got the "me-too" on the reboot hang issue for 2 different Dell R710's with xen-4.2.4-29.el6 and at least the kernels kernel-3.10.25-11.el6.centos.alt.x86_64 and kernel-3.10.23-11.el6.centos.alt.x86_64. I have not tried to reboot with the latest kernel-3.10.32-11.el6.centos.alt.x86_64 (if kernel even makes a difference). I *have* had dom0_mem=1024M,max:1024M option in place for all of them with only 6 VM's.
Any new suggestions?
pjwelsh
On Thu, March 13, 2014 15:49, Reindl Harald wrote:
>
>
> Am 13.03.2014 20:43, schrieb James B. Byrne:
>> CentOS-6.5
>>
>> We have a KVM guest running MS-WinV7pro. This guest is joined to an Active
>> Directory Domain. That domain provides DHCP to the members. The KVM guest
>> does not obtain its IP from the domain but from the local host's qemu
>> hypervisor instead.
>>
>> Is there anyway to get around this and have the guest MS-Win OS get its DHCP
>> from the same place as the rest of the domain members?
>
> smells like you are using NAT for your guest instead
> bridge it to the host network, the guest does not
> know from where it gets DHCP infos and there should
> not be more than one dhcpd on a network segment, anything
> else leads to race-conditions - the faster dhcpd wins
>
> http://www.dedoimedo.com/computers/kvm-bridged.html
>
> maybe the article is outdated, try google as i did
> https://www.google.at/search?q=kvm+nat+versus+bridging
>
>
Yes, that was it. Apparently if one creates a kvm guest via the virt-manager
gui application then NAT is automatically selected as the default. It may be
that the other guests were originally hand-crafted via virsh and the br0
interface was specified for them, but I doubt that. I have been using
virt-manager since day one on this project and I am getting a queasy feeling
that virt-manager's behaviour has obscurely changed in significant ways since
I first began using it. This is not the first problem that I have had creating
new guests with recent versions of virt-manager which were not in evidence
with earlier use.
In any case, to fix this via virt-manager's __virtual hardware details__
interface one must select the __NIC__ and change the settings from <Virtual
network default 'NAT'> to <Specify shared device name> and then input the
bridge interface name <br0> in the text box that subsequently appears. One
must also change the Device model: from <Hypervisor default> to <virtio>.
Thanks for the pointer.
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
CentOS-6.5
We have a KVM guest running MS-WinV7pro. This guest is joined to an Active
Directory Domain. That domain provides DHCP to the members. The KVM guest
does not obtain its IP from the domain but from the local host's qemu
hypervisor instead.
Is there anyway to get around this and have the guest MS-Win OS get its DHCP
from the same place as the rest of the domain members?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
Hi all,
I've reviewed the mailing list archives and it looks like the
"centos.org" AMIs in the marketplace are
really official products of the centos project (whatever that means),
but I wanted to ask explicitly
to confirm.
Presuming yes, I've run into an odd problem with the 6.4 x86_64 AMI (not
updated).
with a few packages, files are not being properly created in
/usr/share/locale/xx/LC_XXXX when I install the RPM.
I mostly don't care about the files themselves, but I worry about what
else is wrong.
I'll use subversion as my example below, but there are about half a
dozen affected packages, including the coreutils
package as shipped in the AMI (ami-bf5021d6).
I have turned off selinux enforcement.
RPM database shows the file:
[root@dns-east svn]# rpm -ql subversion | grep de.LC
/usr/share/locale/de/LC_MESSAGES/subversion.mo
verify doesn't complain:
[root@dns-east svn]# rpm --verify subversion
[ just returns, no output ]
RPM package contains the file:
[root@dns-east svn]# rpm2cpio /tmp/subversion-1.6.11-10.el6_5.x86_64.rpm
| cpio -t | grep de.LC_MESSAGES
23744 blocks
./usr/share/locale/de/LC_MESSAGES/subversion.mo
[root@dns-east svn]# rpm2cpio /tmp/subversion-1.6.11-10.el6_5.x86_64.rpm
| cpio --extract --make-directories
23744 blocks
[root@dns-east svn]# ls -l ./usr/share/locale/de/LC_MESSAGES/
total 308
-rw-r--r--. 1 root root 312655 Mar 13 14:03 subversion.mo
Uninstalling and reinstalling the RPM doesn't help.
There are no crazy install scripts, either.
[root@dns-east svn]# rpm -qp --scripts
../subversion-1.6.11-10.el6_5.x86_64.rpm
postinstall scriptlet (using /bin/sh):
# Register the snvserve service
/sbin/chkconfig --add svnserve 2>&1
/sbin/ldconfig
preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
/sbin/service svnserve stop > /dev/null 2>&1 || :
/sbin/chkconfig --del svnserve > /dev/null 2>&1 || :
fi
postuninstall program: /sbin/ldconfig
[root@dns-east svn]#
--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan
+1 (734)615-7362
https://forums.aws.amazon.com/thread.jspa?messageID=481859񵩃https://forums.aws.amazon.com/thread.jspa?messageID=453572񮯄
This is a timebomb waiting to strike so many people who like do daily snapshot backups and keep them for few weeks and not realizing their snapshots are useless if they had accidentally mess up some boot related file earlier on.
Another scenario you mess up the sudoers file or the root authorized keys - you'd have to loose a whole days data and go to previous nights restore just for single file error like that ?
If AWS marketplace is unable to remove this hardcoded rule then it's only prudent to remove Centos from AWS marketplace and release it in the community section instead ?
Thoughts ?
Hello,
I've been using Xen4CentOS for the last 3 months. It's working fine and
dom0/domUs are stable but the server does a kernel panic when doing a
reboot and the server has to be hard reset manually. It has kernel panic on
the 3 last reboot.
Please stand by while rebooting the system...
INFO: task reboot:19800 blocked for more than 120 seconds
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message
Call trace
...
Picture of the call trace: http://i59.tinypic.com/169olt1.png
CentOS: 6.5
Kernel: 3.10.23-11.el6.centos.alt.x86_64
Xen: 4.2.3
Server: Supermicro 6017R-WRF
Any idea how to troubleshoot or fix this issue? We can't reboot the dom0
during the week because domUs (2) are in production and this server is in a
datacenter.
Kind regards,
Karl