VMware OVA template stuck at Loading initial ramdisk...

[sandabot]

System vms can't deploy properly because the vms won't start as they are stuck at

Dooting "Debian GNU/Linux"
Loading Linux 6.1.0-40-amd64
Loading initial ramdisk

I also tried deploying a vm straight from the vSphere, downloading the template from https://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.2-x86_64-vmware.ova

Changed the SCSI controller from LSI Logic Paralel/LSI Logic SAS/VMware paravirtual, it will won't deploy.

Also tried moving the root disk to different datastores, it won't help

Anyone faced this with the latest vmware template? Any other places I should look at? I'm using vSphere 8

[weizhouapache]

it works for me

OS type is: Debian GNU/Linux 12 (64-bit)

VM settings:

[weizhouapache]

some screenshots

and

and

the host is VMware ESXi, 8.0.3, 24022510

[sandabot]

Thanks for the screenshots! They provide some valuable context. One thing I'm noticing is that my system VMs are connected to these two port groups: cloud.private.untagged.0.1-vSwitch0 & cloud.public.untagged.0.1-vSwitch0 . I haven't defined any guest networks so far and they pull their public ips from the public IP pool and the the private ips from the management network pool . My question is: Which is the correct network these system VMs should be connected to in VSphere?

[weizhouapache]

if you does not specify the network traffic label, the system vms will connect to vSwitch0 which is default vswitch name.
you can specify the traffic label of physical networks.

for example, in my testing env

• management network

- public network

[sandabot]

vSwitch0 is the network label I'm using, so that should be fine. Could you tell me how I should handle vlan traffic? The management network is in some 123 vlan, but if I try tagging it in here, the vms will error and won't start.

Also, is it possible that the networking should be the root cause of why the system vm's won't reach the booting phase?

Also, I'm using vSphere 8, from the 4.21 documentation, it says that

"VMware vCenter Standard Edition 6.0, 6.5, 6.7, or 7.0 must be installed and available to manage the vSphere hosts.". Could this be the cause of incompatibility?

[weizhouapache]

Also, I'm using vSphere 8, from the 4.21 documentation, it says that

"VMware vCenter Standard Edition 6.0, 6.5, 6.7, or 7.0 must be installed and available to manage the vSphere hosts.". Could this be the cause of incompatibility?

This doc needs to be updated.
8.0.x is supported

[sandabot]

also tried deploying it directly from an entirelly different esxi machine, same result.

At this point I'm wondering if cloudstack injects some settings into the vsphere api call and there' s some missconfiguration on my side.

Can anyone deploy the .ova template directly into vsphere without having cloudstack involved?

[sandabot]

Any ideas? As an update, the system vm template, version up to 4.19, deployed on it's own will boot with no issues.

So noticing this, I installed cloudstack 4.19 to test the connexion but those system vms will not boot, they will remain stuck on loading initial ramdisk.

I'm thinking I'm not passing some important configuration from cloudstack, because why would a template boot
when it's deployed on it's own (https://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-vmware.ova) while the same template, when it's launched by cloudstack as a system vm, with all the corresponding configuration will get stuck at boot?

Also, the console isn't opening for cloudstack-orchestrated system vms

[DaanHoogland]

did you look at the service offerings for systemVMs?

[sandabot]

These are the default ones, I also created some custom offerings with greater limits, the system vms are created with these new limits but they won't boot.

Also, the vsphere console isn't working on these system vms

I downgraded the version to 4.19 , that specific systemvm template can boot while deployed individually, but somehow the cloudstack deployment messes it up within the vm reconfiguring phase.

I believe there is some disk issue but I can't figure it out

Let's take the v-10-VM:

I'm seeing different values in cloudstack vs vpshere. Only the systemvm template is 0.45 GB

[DaanHoogland]

Does that systemvm template works for the console proxy itself, or is it failing to show a console as well? If not, maybe you need to destroy the console proxy and let it be re-created.

[sandabot]

Just as an update for this issue: I've downgraded the entire cloudstack build tu 4.19.3, including the systemvmteplate to that corresponding version and it works. The main issue was that any systemvm template >4.20, the ones that are based off debian 11 will not boot. I've tested it on 3 different vmware environments with different esxi versions. Any ideea why? Do the newer templates need some sort of configuration beforehand in order for them to properly boot?