ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

RouterOS Virtualization
1

Hi,

I installed Mikrotik CHR from ova file downloaded from Mikrotik’s website.

It seems to run perfectly fine until I want to change the disk size.

From the console it says ‘resizing disk’ and then I get the attached image as an error in a continuous boot loop - any ideas?

Edit: I tried it on VirtualBox and get the same result…
Capture.PNG

2

You need to resize the disk before powering on the VM for the first time.

It should automatically resize on the first boot.

3

Thanks, I thought of this also but tried it again just to make sure - the same result…

4

Send a bug report to support. They may see it here, but officially it’s only user forum, so they can miss it.

5

Thanks, just did that :slight_smile:

6

This has been solved with help from support to re-read the information here https://wiki.mikrotik.com/wiki/Manual:CHR_VMWare_installation

I somehow missed that one has to set the disk to IDE Master even though the ovf imported using the SCSI interface.

So it runs fine on the SCSI interface until you need to resize the disk then it fails - changing the drive type to IDE (PATA) solves the kernel panic and CHR completes the resize and starts up perfectly fine.

Just thought I’d post the solution here in case someone else has a similar issue.

7

Honestly, it sounds kind of stupid to me. Both having to use IDE disk and RouterOS crashing like this and it not being a bug. And in fact, none of my CHRs have IDE disk, I have SCSI everywhere and it works great. Although it’s true that I didn’t use OVA, I just took disk image and when I needed to resize it, I did it with qemu-img before I first connected it.

8

There seems to be something wrong with virtual disk in OVA.

I normally download CHR in “raw disk image” format and then I convert it to vmdk myself. I don’t exactly remember why, either there wasn’t vmdk at the beginning at all, or there was some problem just uploading it to ESXi as bare file. I think it was the latter, it complained about wrong format or something.

I do this (adapter_type=lsilogic is only because qemu-image doesn’t like pvscsi):

qemu-img.exe resize -f raw chr-6.44.3.img 128MB
qemu-img.exe convert -o adapter_type=lsilogic,subformat=monolithicFlat -f raw -O vmdk chr-6.44.3.img mikrotik-chr.vmdk

Then I upload resulting mikrotik-chr.vmdk and mikrotik-chr-flat.vmdk to ESXi (they get merged into one, at least in UI) and select it as new disk (connected to pvscsi controller). And it works great. Even resizing works. Shut the VM down, set larger disk size, start it again and it will occupy new free space. I can repeat it again and again and it still works. So in fact my initial img resizing should not even be necessary, it’s a relict from the past when I think CHR supported resizing only on first start and not further, and I wanted to be sure that I will have enough space for the future.

But here’s the thing, now I tried to skip the first step (qemu-img resize) and only converted MikroTik’s original img to vmdk. And surprise, the resulting vmdk crashes CHR when resized, exactly as the one from OVA.

9

I can confirm that I have reproduced this problem within the limitations outlined which says it actually has a minimum disk size requirement of 128MB even though the OVF imported and created and successfully booted from a 64MB disk?

It booted successfully with the original 64MB disk image that comes with the OVF but as can be seen below when increasing it to 128MB it causes a kernel panic as was the origin of my original post.

To make things further confusing is that editing the VM again and increasing the disk size to 256MB results in a successful resize and subsequent boot of CHR as can be seen on the attached images… so there’s definitely a bug lurking in there somewhere especially given that my resized 256MB disk boots successfully from SCSI and I did not need to reconfigure the hard disk to emulate IDE… say what?





Thanks, so there is some or the other bug lurking around in there somewhere… perhaps I was just unlucky enough to get stuck with that. Obviously following the original instructions at the link provided causes me to nuke the original install and start from scratch so it could be that I need to skip something to reproduce the error
Step1.PNG
Step2.PNG
Step3.PNG
Step5.PNG
Step4.PNG
Step6.PNG
Step8.PNG
Step7.PNG
Step10.PNG
Step9.PNG
Step11.PNG

10

My experience with CHR deployed from the official OVA template:

Disk size 64MB (default) - successful boot.
Disk size 128MB/127MB/65MB - kernel panic.
Disk size 129MB - sucessful boot.

So, it seems, any value less than or equal to 128MB leads to a failure (except the default 64MB). I didn’t check all the possible values between 64 and 128, but the pattern is pretty clear.

Bus type is SCSI in my case.

11

Same experience in GNS3 (QEMU) on linux. Boot loop with CHR image sizes 65…128MB. Bus type is virtio.

Tried versions chr-6.45.9.img and chr-6.47.2.img.

By the way, chr-7.1beta2.img doesn’t have this bug, I’ve successfully booted 100MB image.

12

You save my day: I read that disk resizing is automatic and just changed it from 64 to 128 MB in the ESXi interface, causing kernel panic. After changing the disk size to 129 MB CHR started without problems, automatically resizing to 128 MB and everything keeps working.