The CloudStack Collaboration Conference is just month away. If you still have not decided to come, take a look on the agenda and register: https://www.cloudstackcollab.org/
An insightful event with many technical talks, sessions, option to Get CloudStack Certified and meet fellow CloudStack users!
I’m building V2K Migrate, a self-hosted tool for moving VMs from VMware vSphere to Apache CloudStack on KVM. I’m looking for beta testers who can try it in labs different from mine and tell me where the migration assumptions break.
For background: I’m an Apache CloudStack PMC member and have spent years working with VMware, KVM, and CloudStack migrations. I built V2K for the larger, repeatable migration job, where storage and network mappings, warm cutovers, and per-VM outcomes have to hold together across a fleet.
V2K Migrate is completely free to use. This is a beta, not a claim that every workload or large deployment is already proven.
The CloudStack path has completed end-to-end lab migrations, not just disk exports. The workflow inventories and checks the source VM, reads its disks through strict VDDK HotAdd, converts the guest for KVM, and has CloudStack adopt the resulting VM and volumes. I’ve also completed migration tests using NFS/QCOW2, Ceph/RBD, and LINSTOR/DRBD storage. Each path needs the matching CloudStack primary storage and an explicit pool mapping.
At fleet scale, the source read path matters. V2K’s worker uses VDDK HotAdd to attach and read snapshot-backed VMDKs inside vSphere; it does not silently fall back to NBD/NFC network reads, which pull the same data over the ESXi management interface and can saturate it and stall migrations when that traffic isn’t isolated. This is an established pattern from the backup world: Veeam’s virtual backup proxies use VMware SCSI HotAdd to read VM disks directly from the datastore, and V2K applies the same source-side transport to migration. End-to-end speed still depends on the datastore, worker, destination path, and conversion.
Before starting, the operator can select the destination zone, cluster, compute offering, and disk offering, map each source disk to destination storage, and map VMware port groups to CloudStack networks. When exactly one destination network has the same known VLAN as a source port group, the UI proposes that mapping for review; when the match is ambiguous, it leaves the mapping empty for the operator to pick. Root/data disk controllers and NIC model are selectable, with VirtIO as the default for converted guests.
Public V2K Migrate demo screenshot — synthetic data, not a live deployment.
What I’ve tested so far includes:
A cold Ubuntu 24.04 migration to CloudStack/KVM, followed by boot, guest checks, and reboot.
A warm Windows Server 2019 migration with two disks and two NICs: a baseline while the VMware VM remained running, repeated CBT delta passes, final cutover, CloudStack import, and successful guest checks after boot and reboot. One NIC retained a static IPv4 address; the other used DHCP.
A two-disk Ubuntu guest whose root LVM spans both disks; its storage and boot path were verified after migration.
A cold, storage-only handoff of a 17-disk VM — a clone of a vCenter Server Appliance (vSphere 8.0.3), picked purely as a multi-disk stress test. All 17 disks landed as QCOW2 on NFS, the source-to-target data check sampled ~4.4 GiB from each side across 1,122 regions, and the JSON descriptor mapped every disk's controller, unit, order, and capacity. That includes the unit-7 gap vSphere reserves for the SCSI controller, so a receiving importer sees the original unit numbers rather than a renumbered sequence. I didn't attempt to boot it on KVM — running a VCSA off ESXi wasn't the point; the disk layout was.
For Windows, the optional Preserve static IPs setting can retain the source MAC and static IPv4 configuration automatically when the tool is sure which source NIC it is and the mapped CloudStack network is compatible. If those conditions aren’t met, the NIC comes up without the old address and the migration report says why. I wrote up why the guest and CloudStack network records both matter. Linux needs separate care: some distributions rename interfaces after the virtual NIC changes, so guest-side network configuration and connectivity must be checked after boot.
When VMware Tools data is missing or stale, V2K can inspect the source guest without writing to its disks. A powered-off VM is read directly through VDDK HotAdd; for a running VM, V2K creates a temporary snapshot and reads its VMDKs read-only. virt-inspector identifies the OS, while separate read-only inspection of Windows registry data or Linux network configuration can recover configured addresses and match them to source NICs when the evidence is clear. Even a powered-off VM with no current IP reported by VMware Tools can yield its saved network settings this way. DHCP leases stay clearly separated from confirmed static IPs.
Public V2K Migrate demo screenshot — synthetic data, not a live deployment.
For warm migration, the source stays powered on through the baseline and repeated delta passes. It is shut down for the final delta and cutover; downtime depends on the guest, remaining changes, storage, and conversion work. V2K does not delete or overwrite the VMware source VM or its disks. It creates and cleans up temporary migration snapshots, and leaves the source available for rollback. This is still a beta: I’d start with a disposable VM or an independently backed-up test workload.
V2K Migrate also supports a separate, direct Proxmox VE destination; here’s my Proxmox beta post if that’s relevant to your environment. This CloudStack path targets CloudStack/KVM, not CloudStack managing Proxmox.
There is also a storage-only (disk-only) handoff for operators who want the migrated disks without automatic creation of a destination VM. Alongside the disk outputs, V2K provides a detailed JSON descriptor and generated libvirt domain XML. The descriptor records the source NICs and MAC addresses, available IP information, and each disk’s source controller and unit, order, capacity, and destination target, so the receiving operator has an explicit map for a manual import.
V2K Migrate control plane — the 17-disk storage-only handoff from a real lab run (lab data, generic names).
If you have a non-production vSphere and CloudStack/KVM lab, register your interest using the beta-testing option on the main site’s signup form. I’m collecting interest now and will contact testers once the beta package and its third-party licensing are sorted out. I’m particularly interested in real-world disk layouts, network mappings, and what you need to verify before trusting a cutover. The public interface demo uses synthetic data, has no connected infrastructure, and cannot run migrations.
For those running CloudStack today: what has bitten you hardest in a VMware-to-CloudStack move?
I’m excited to share that I’ve partnered with the team at ShapeBlue to kick off a new CloudStack USA User Group over on LinkedIn.
If you've spent much time in the ecosystem, you've probably noticed that a massive majority of the active CloudStack community seems to be based out of Europe and India. While that global network is incredible, we want to focus on growing and connecting the community right here in the US.
Whether you’re a long-time contributor, managing large-scale multi-region deployments, or just starting to design your private cloud, we’d love to have you join the conversation. Our goal is to build a strong network for professionals over here to connect, share best practices, and support each other's work.
The group is really small right now, but hoping to really grow and get to the point we can hold in-person events.
I'm new to the Apache CloudStack environment and have started building a POC. I'm using XCP-NG as the underlying platform. Originally I come from VMware and am considering removing the product from our portfolio due to the current conditions imposed by Broadcom.
There's one thing I don't quite understand, and I was hoping you could help me with it.
I've configured the networking on the XCP side: MGMT, SAN, Live Migration, etc. These are all on different VLANs. MGMT is running on a 1 Gbps connection, while SAN and Live Migration are each on their own 25 Gbps fiber optic adapters. I can reach everything and it's working. I've also assigned the corresponding labels.
I installed CloudStack as a VM and started the setup. All hosts have been added successfully. However, I then got an error that storage cannot be added. By the way, I'm using XCP-NG 8.2 and CloudStack 4.20.
In the logs I could see a message for the networks from the zone (i.e. the physical networks) that basically said something like "I can't create a VLAN on a VLAN". This means CloudStack recognized the existing configuration on XCP-NG. I actually thought that by assigning the labels I was telling it which physical network to use, and not that CloudStack should try to create a new one.
Additionally, I can't access the Secondary Storage. Unlike Primary Storage, which is connected through the hosts, it seems CloudStack wants to reach Secondary Storage via the MGMT interface of the Cloudstack VM. That obviously doesn't work, because only the SAN interface/adapter has the necessary connectivity. How can I tell CloudStack to use exactly this path via the SAN adapter? Adding a PIF with an IP address from the SAN network didn't help.
Please don't stone me — I've read a lot and implemented quite a bit in this POC, but these points just aren't becoming clear to me.
TLDR: Besides docs are there any other resources to learn Apache Cloudstack. Thanks.
I work at IT business, we of IaaS, PaaS and SaaS. We have being using VMware for our Datacenter and we plan on moving to self service system for clients (because we were manually provisioning VMs and given clients ssh access). As we were looking we landed on ZStack but we ain't really happy with it plus the pricing isnt favourable.
We looked for alternatives and at the moment Apache Cloudstack looks like what we would like to have. I have been tasked with doing research and training so I can present it to management.
So my question besides the docs what other resources can be used to understand Apache Cloudstack.
PS, I am visual learn, so videos will really do well for me😅
I’m currently working on integrating Apache CloudStack with Proxmox and I’m hitting a bit of a wall regarding automated networking.
Specifically, I’m trying to deploy instances where CloudStack handles the IP assignment and passes that configuration to the guest OS via Cloud-Init.
Does the Proxmox extension in CloudStack automatically update the Proxmox VM's "Cloud-Init" network settings, or do I need to pass a specific user-data string during deployment?
Has anyone had issues with the Cloud-Init datasource being set to NoCloud vs CloudStack when running on Proxmox?
Are there any specific global settings in CloudStack I need to toggle to ensure the metadata is passed correctly to the PVE API?
Any advice or example configurations would be hugely appreciated!
Hello everyone, I'm running a lab in ACS (Apache CloudStack) with Object Storage in my 4.22 environment (the latest version). It connected to my CEPH RGW, and I was able to create buckets. However, when I go into the buckets I created and try to do an UPLOAD of any file type, I get an error message. But when I upload via awscli from my manager node, it works fine. I believe it might be a UI bug in ACS for Object Storage. I appreciate any help. Thanks.
I'm running some automation tests with Ansible, but I'm struggling a bit to get it done.
Is anyone already using Ansible to manage a CloudStack environment?
Could you help me with tips or point me to places with information so I can win this battle?
Over at r/selfhosted, asked for any open-source private cloud platforms. Apache Cloudstack was a recommendation.
With version 4.22 of Cloudstack, Proxmox console access is now available.
With that being said, does Cloudstack support Proxmox clusters for nested virtualization?
I plan to use it to manage a 5-node Proxmox Ceph cluster. The plan is to have individuals spin up Proxmox instances and create a cluster of them and run VMs in this virtual cluster. This is obviously nested virtualization.
Is there anything that shows how to do a basic 3 node setup with virtual routers/port forwarding and a mgmt/public (vlan60/DMZ)/and storage (vlan70). I have 4 machines 3 are going to be nodes with 4 nics bonded and 1 is already setup as the management machine with 2 nics, and just trying to figure out a simple setup with those basic requirements. Going to be hosting a few projects and want isolation. One of the nodes will have storage duties as well as some compute. I want local disk as well as nfs storage as a choice. Just want some direction as i am trying to rtfm but it can be a bit all over the place.
Im running Ubuntu 24.04 on all the nodes and management machine
I've currently got a 5-node Proxmox cluster running a couple hundred KVM/QEMU VMs. Storage for VM primary disk on all nodes is local but I do have an NFS server too for some larger spinning rust disks.
I want to migrate all of these from Proxmox into my fresh CloudStack environment - separate ceph cluster, 5 compute nodes. It's just KVM right - what would the process be?
questions: What files need to be edited and their parameters so CloudStack Agent stays running?
details:
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
I cannot for the life of me, get the management server to connect to the host.
I have noticed that the agent will never stay running. I could not find documentation on what settings need to be configured for the agent to run. I have gone down so many rabbit holes and looked at forms and asked AI for help, but no solution has worked.
Errors:
loudstack-agent.service: Main process exited, code=exited, status=1/FAILURE
cloudstack-agent.service: Failed with result 'exit-code'.
cloudstack-agent.service: Referenced but unset environment variable evaluates>...skipping...
cloudstack-agent.service: Main process exited, code=exited, status=67/NOUSER
cloudstack-agent.service: Scheduled restart job, restart counter is at 70 (and counting).
I also noticed:
In the /etc/cloudstack/agent/agent.properties, there are unset parameters but could not find documentation on what to set them to, or what format it expects things in.
thank you for your time, just unsure what needs to be set.
First-time poster here. I finally decided to start experimenting with building a homelab, and I'm documenting the entire process on GitHub. The tech stack is as follows:
Canonical MaaS: Managing and provisioning physical servers
Apache CloudStack: Infrastructure as a Service (IaaS) cloud computing platform
Cilium: Advanced networking & observability on Kubernetes
Traefik: Reverse proxy, ingress controller, and API gateway on Kubernetes
I have been tinkering with standardising the deployment and configuration process. I currently have Windows 11 and Ubuntu 24.04 VMs running and a 3-node CKS-managed Kubernetes cluster with Cilium CNI, Traefik ingress, and Knative for deploying serverless applications that scale based on traffic and cluster capacity. Canonical's MaaS is very handy for configuring and deploying the physical servers that will run CloudStack.
Any suggestions or recommendations would be helpful. I will continue to update the repo on GitHub to reflect the homelab's state, and Terraform will be used to manage the CloudStack environment.
The final homelab is to host applications such as NextCloud, Jellyfin, Tailscale for ZTNA, and Cloudflare tunnels for making services public. It's also to experiment with various cloud security tools. I work as an Infrastructure Security Engineer, so it's handy to test various cloud-native security tools without dealing with the hyperscalers (shocker, I'm not a fan even though I use all three daily).
How should I get started with CloudStack? Proxmox is familiar in itself and has received support. How should I, for example, build a network or implement a CloudStack and Proxmox combination?
i currently have only on Physical Server with on which i would like to deploy all the component need for Apache CoudStack with in mind to scale it later.
My server (is a dedicated Hetzer root) with below specification are:
2Tb SSD
128 Gb RAM
12 core AMD Ryzen 9 3600
For all tutorial i have read, most of them mentioned
installing the Management Server+DB of Apache CloudStatck on the base system
install a hypervisor (KVM)
and install al other thing inside VM on top of KVM
With those tutorial's topology i am confuse and was just wondering if it's really benefit in case you need to reboot MGMT server? Would this not issue downtime for other VM? will not be better to install MGMT server inside a VM based KVM
Does anybody have any tips or resources on setting up CloudStack behind a Juniper Collapsed Core Fabric? We were hitting session limits and need to start scaling horizontally. Just wondering how people tackled the network management in CloudStack in a horizontally scalable, zero down time way? Thanks!
Hi, il need someone who installed and configurated cloudstack before to help me a bit with the setup, i used openstack before and for me was easier to understand openstack than cloudstack... well openstack needs much time and is hard to manage alone, but i dont find anyone who can help me without 1000$....
My cloudstack api url for create user is like http://cloudstack-host/client/api?account=<account>&command=createUser&email=userthree%40mail.com&firstname=User&lastname=Three&password=password&response=json&username=userthree&signature=<signature>
It rejects me with 401
It is happening only in createUser and createAccount APIs
If someone know what is happening here, I really appreciate for your help
I’m having a big issue with my Apache CloudStack setup and I’m running out of ideas. Context:
CloudStack 4.x with KVM hypervisors
Primary storage: iSCSI (TrueNAS) mounted on KVM host
Secondary storage: NFS
Trying to deploy a new Secondary Storage VM (SSVM) in a zone
The problem:
When CloudStack tries to deploy the SSVM, it fails at the step where it needs to copy the system VM template to the primary storage.
The SSVM never starts, and the management server logs show errors like:
textUnable to create volume [...] due to [com.cloud.utils.exception.CloudRuntimeException: Can't find volume:...] Resource [StoragePool:3] is unreachable: Unable to create volume [...]
On the KVM host, the primary storage is mounted (/mnt/primary01), but it is empty.
The system VM template is present on the secondary storage (NFS), but apparently never copied to the primary.
What I’ve tried:
Verified that /mnt/primary01 is mounted and accessible from the KVM host (but it’s empty).
Checked that the template exists on the secondary storage.
Refreshed the libvirt storage pool with virsh pool-refresh.