Is your virtual server with old kernel on xen hypervisors not booting? We can help you.

At times, some Virtual Servers crash with kernel panics on startup on Xen hypervisors to get access to all CPUs of the hypervisor despite the configuration made in the UI.

Here at Bobcares, we handle requests from our customers to fix similar errors as a part of our Server Management Services.

Today we will see how our Support Engineers fix this for our customers.

How to fix virtual server with old kernel on xen hypervisors not booting issue

Before going into the steps for fixing this error we will see what causes this error.

Cause

One of the causes for this boot issue is switching to use the libvirt tool stack instead of xl on Xen hypervisors.

The XML config allows Virtual Servers to get access to all CPUs available on the HV but limited to a number set in the UI.  Furthermore, tt allows supporting hot resize features. However old kernels are unable to serve more than 32 vCPUs that are passed to them.

A virtual server configured with one core  <vcpu current=\”1\”>32</vcpu> on the hypervisor will actually have the VS with 32 vCPUs:

Steps to fix:

To fix the boot issue we can install a newer kernel that is greater than or equal to version 2.6.32

In order to install the newer kernel, we have to boot the Virtual Server in the Recovery mode.

1. Firstly, we have to reboot in recovery.

2. For this we have to login via recovery with user/password being root/recovery or root/defaultrootpassword. If recovery does not work, we can try the default root password listed in the properties of the virtual machine. We can use the following command:

fdisk -l

3. After that we have to check for the disk that has the same size as the one this VM has. Generally it is /dev/vda or /dev/xvda. It will also show the partitions, and it will more than likely be the /dev/vda1 partition.

4. Now we can mount that disk using the following command:

mkdir /mnt/vda1

mount /dev/vda1 /mnt/vda1

5. For making the environment usable, we must bind /proc, /sys, and /dev to the environment using the following:

mount --bind /proc /mnt/vda1/proc

mount --bind /sys /mnt/vda1/sys

mount --bind /dev /mnt/vda1/dev

6. Finally, we will ‘change root’ to the environment using the following:

chroot /mnt/vda1

[Need assistance? We can help you]

Conclusion

In short, we saw the steps that our Support Techs follow for fixing this boot issue.