CubeCOS FAQ
What is CubeCOSβ
CubeCOS is an open-source cloud platform that manages both virtual machines and Kubernetes workloads from a single control plane. It's built on OpenStack, Ceph, and Kubernetes, and it's licensed under the Apache 2.0 license. CubeCOS provides software-defined networking, distributed storage, high availability, workload migration, platform automation, and IT self-service. Optional modules extend it with additional functionality, such as CubeVDI, CubeCMP, and CubeDPX.
Is CubeCOS really open source, or is there a catchβ
CubeCOS is fully open-source software built on OpenStack, Ceph, and Kubernetes, and licensed under the Apache 2.0 license.
Can I run CubeCOS on existing VMware-certified hardwareβ
CubeCOS usually runs on standard x86 server hardware without requiring a specific vendor's reference architecture.
Does CubeCOS support live migration of running virtual machinesβ
CubeCOS supports live migration of running virtual machines between hosts using standard KVM live migration backed by OpenStack Nova.
How does CubeCOS simplify OpenStack operationsβ
CubeCOS uses Hex Bedrock, a custom orchestration framework that automates deployment, integration, and operation. It reduces operational overhead and enables reproducible lifecycle management at any scale.
Where can I deploy CubeCOSβ
You can deploy CubeCOS in private clouds, public clouds, and edge environments. It's designed to support both large-scale data center deployments and resource-constrained edge environments.
What's next on the CubeCOS roadmapβ
Upcoming features include support for external storage systems, deeper health automation, a more intuitive UI experience, and advanced monitoring capabilities in future releases. See the release notes for the latest updates.
How do I launch a virtual machine on CubeCOSβ
Use a prebuilt cloud image from your preferred distribution, such as CentOS, Rocky, or Ubuntu. Upload the image, create a project to organize resources, configure the VM's allocated resources, and launch the VM. See Launch your first instance for the full procedure.
What are cloud images, and why does CubeCOS use them for VM deploymentβ
Cloud images are lightweight, pre-configured operating system images optimized for cloud environments. They support cloud-init, which automates initial configuration such as setting hostnames, SSH keys, and user accounts.
Why do I need to create a project before provisioning VMsβ
Projects (tenants) provide resource isolation, access control, and usage tracking in multi-tenant cloud environments. They help you organize VMs, apply quotas, and separate environments.
How do I connect to a VM after it's deployedβ
Connect to your provisioned virtual machine through SSH using the assigned IP address and your SSH key pair, or through the CubeCOS web-based virtual console.
Do I need to configure networking before creating a VMβ
Yes. Configuring a virtual network is required to assign IP addresses and enable communication for your VM.
What causes a Linux kernel panic during system bootβ
A kernel panic typically occurs when the operating system encounters an unrecoverable error or fatal exception. The most common cause is a missing or incompatible driver, especially a filesystem driver required to mount the root (/) directory at boot.
How can kernel version drift lead to a system failureβ
Kernel version drift happens when an unmanaged kernel version is introduced through an upstream repository update. For example, if the kernel changes version without explicit version control, it can introduce a compatibility issue that causes a panic during boot.
How do I troubleshoot a kernel panic on a remote clusterβ
Rely on the serial console through an out-of-band management interface, such as BMC or IPMI. For systems without a built-in BMC or IPMI, use an IP-VGA adapter or a DIY console server with an RS-232 serial interface.
How do I prevent kernel version drift on RHEL-based systemsβ
Use the versionlock plugin to lock critical packages, such as the Linux kernel, to a known, tested, and working version.