When booting the server, the host would come up and start the process of booting the containers, then at some point during the boot process it would reboot without any errors.

I managed to break the reboot loop by quickly SSHing in to the host node whilst it was starting the containers and disable the “vz” service so that it wasn’t started at boot time:

chkconfig vz off

On the next reboot, this broke the reboot loop and allowed me to get in via SSH and look around the system properly.

The only hint that I had to go on was that whilst most of the containers brought up during the boot sequence said “starting container”, the container immediately prior to the unexpected reboot said “restoring” instead.

This prompted me to look in the “/vz/dump/” folder, where I found a file called “Dump.” (Obviously was the container ID of the container which was being restored instead of started).

Simply removing this dump file allowed the “vz” service to be started without causing a reboot and everything started working as normal.

The only thing left to do at this point is to remember to enable the “vz” service again so that it will start during the next system boot:

chkconfig vz on

The post OpenVZ reboot loop first appeared on Spheron1.

php /usr/local/solusvm/includes/xenkernel.php

This not only re-creates the /boot/solus-vmlinuz symlink to the appropriate vmlinuz file, but also builds the necessary /boot/solus-initrd.img initial RAM disk to boot your DomU machines.

Of course, if you are using PyGrub then you don’t use these files in Dom0

The post Missing kernel initial RAM disk with SolusVM and Xen first appeared on Spheron1.