What importing qcow2 and raw VM disk images into Ceph RBD involves
The short answer on effort is that it depends on how many disks you are moving, how large they are, which formats they use, how fast the network between your hypervisors and Ceph is, and how much downtime the owning teams will accept. A handful of small raw images over a fast network is a very different job from hundreds of multi-terabyte qcow2 files with snapshot chains. The import-only live migration path in RBD exists so that you do not have to pick between a long outage and a risky copy: the VM can keep running on its source disk while its data is copied into an RBD image, and you cut over once the copy is complete and committed.
Before planning the work, inventory every disk the VMs use. For each one, record the source path, format (raw or qcow2), virtual size, whether it has backing files or internal snapshots, and which VM and hypervisor own it. Those details decide which import streams are available, how long each copy will run, and whether a disk needs to be flattened first. Confirm the supported formats and stream types for your Ceph release in the Ceph documentation, since the import-only path has version and client requirements that vary, and check them against the hypervisor and client versions you actually run. Also confirm how your hypervisor attaches RBD images, because cutover is only as clean as the VM definition change that follows.
Which qcow2 and raw features map to RBD images and which need a decision
This table compares what each source disk feature does in qcow2 or raw form with its outcome after import into an RBD image. Read each row as either a direct mapping or a decision you must make before the import starts. Most of the risk sits in backing chains, snapshots, encryption and the guest-visible disk identity, so confirm those with the Ceph documentation for your release.
| Feature | Behavior in the source | RBD outcome or decision |
|---|---|---|
| Raw images | Flat block image with a direct mapping from offset to disk data | Maps to an RBD image of the same virtual size. Confirm the supported import stream formats for your release. |
| qcow2 backing chains | An overlay depends on a read-only base image | Decision: flatten the chain before import or keep the base available during migration. Confirm backing file handling in the migration docs. |
| Internal snapshots | Point-in-time states stored inside the qcow2 file | Decision: import only the active disk, then recreate needed history as RBD snapshots. Confirm what the import carries across. |
| Compression | Compressed clusters inside qcow2 reduce file size on disk | Data lands uncompressed in the RBD image. Compression at the pool level is a separate decision with its own trade-offs. |
| Encryption | qcow2 or LUKS encryption protects data at rest in the file | Decision: confirm whether encrypted sources import as-is, and plan how keys reach the hypervisor before cutover. |
| Sparse allocation | Unwritten blocks take no space in the file | RBD allocates objects on write, so unwritten regions usually take no space. Confirm zero and discard handling on your path. |
| VM definition in the hypervisor | Domain XML defines disks, controllers, NICs and boot order | Stays on the hypervisor. Update the disk source to the Ceph pool and image name, and keep the device model where possible. |
| Device path and guest disk identity | Guest sees the disk through its bus, model and serial or UUID | Changes: the host path becomes a Ceph source. Guest-visible identity can shift if bus or serial changes, so test boot and fstab before cutover. |
Documented import paths for VM disks into Ceph RBD
Ceph and the hypervisor ecosystem offer several ways to move a VM disk into an RBD image, and each one fits a different downtime budget and source format. The cards below describe each path, what it accepts, and what to confirm against the documentation for the release your cluster runs before you pick one.
RBD import-only live migration
This workflow lets a VM keep running on the source image while RBD copies its data to a new target image. The sequence is prepare, execute, then commit, and the target is attached to the VM only after the copy is complete. Confirm which source formats and streams the release accepts, how the source is exposed to the copy, and whether your hypervisor and client versions support the attach step. Check the supported formats for your release before planning cutover.
rbd import and import-diff
The rbd import command creates an RBD image from a file or stream while the source VM is stopped or its disk is quiesced. The import-diff command applies an incremental difference on top of an existing image, which suits a seed copy followed by short delta syncs. Confirm the flags that your release supports for sparse handling, image features, and the snapshot names used in the diff chain. Consistent snapshots on both sides matter for a correct delta.
qemu-img convert to an RBD target
qemu-img can read qcow2 and raw sources and write them directly to an RBD image using its rbd protocol driver, which avoids an intermediate file. It is useful for one-off conversions and for moving between formats in the same step. Confirm that your qemu-img build includes the rbd driver, the cluster and keyring options it expects, and the output format and cache settings recommended for your Ceph release. Copies run offline unless the source is itself a consistent snapshot.
Hypervisor storage migration tooling
Many hypervisors ship their own storage migration features that copy disks to a Ceph-backed pool while the guest runs, and these tools handle attachment and cleanup for you. The trade-off is that behavior, supported source types, and failure handling depend on the hypervisor version and its Ceph client integration. Ask the hypervisor vendor which Ceph release range it certifies, how it reports progress and errors, and how it rolls back a failed copy. Pair this with the Ceph integration pages for your platform.
Steps for importing VM disk images into Ceph RBD without stopping the VM
This sequence moves each VM disk from its qcow2 or raw source file onto an RBD image while the guest keeps running. It ends with VMs booting from Ceph, and the source files are kept until the import is committed and then retired under your retention policy.
Inventory disks and audit their formats
Record every VM disk with its source path, format, virtual size, backing chain, snapshots, guest OS and owning application. Flag any disk whose format or stream is not on the supported list for your Ceph release, and confirm that list in the release documentation before planning the batch. Done when the owner signs off on a per-disk inventory and each flagged disk has a separate route or is excluded from this batch.
Confirm cluster and network readiness
Check that the target pool exists with the replication or erasure coding and failure domains from your design, that the cluster reports healthy, and that each hypervisor holds a cephx client identity limited to the pools it needs. Measure the network path from each hypervisor to the OSD hosts and confirm there is headroom for copy traffic on top of production I/O. Done when a test image can be written and read from the hypervisor through the same path the migration will use.
Pilot one low-risk VM
Choose one VM with a known boot process and a restorable backup, then run the full sequence on it in a test window agreed with its owner. Record how the copy affects guest latency and throughput, and whether the guest boots cleanly from the Ceph image. Done when the pilot notes list each observed effect and the team decides whether to adjust the batch plan based on those results.
Prepare the import and link the target image
Run
rbd migration preparefor the disk, which creates the target RBD image and links it to the source specification so reads can reach the source while data moves. Confirm in the release documentation whether the guest attaches to the target at this point or only after the copy starts, because that sets when the VM definition changes. Done when the migration status shows the prepared state and the source file is unchanged.Execute the copy while the guest runs
Run
rbd migration executeto start the background copy from the source into the RBD image, and let the guest keep writing through its normal path. Watch OSD latency, recovery load, hypervisor network use and guest response times against the limits set in the pilot, and pause or slow the copy if production work suffers. Done when migration status reports the copy as complete and no alerts remain open for the affected pools.Verify data and boot behavior before commit
Compare checksums on a sample of files or blocks against the source, run the filesystem and application checks the owner specified, and boot the VM from the Ceph image in a controlled window. This is the rollback point: until commit, the source file remains intact and the migration can be stopped with
rbd migration abort, returning the disk to the source as the release documentation describes. Done when the owner signs a test record for each VM.Commit the import and cut over the VM definition
After sign-off, run
rbd migration commit. The parallel run ends at commit, so the source is no longer part of the live path and an abort is no longer available. Update the hypervisor or platform definition so the VM references the RBD image, remove leftover references to the source file, and start the VM from its new definition. Done when the VM runs from Ceph, the inventory marks the source as superseded, and the change record is closed.Decommission source files after retention
Keep the source files for the retention period set by your data policy, with a restorable backup of each VM taken on Ceph before deletion. Then remove the source files, delete any snapshots or copies no longer needed, and update configuration management and asset records. Done when each inventory entry shows the deletion date and the backup restore test has passed.
How the VM keeps running while the disk copies
During the execute phase the guest keeps reading and writing its disk as normal, and the copy runs in the background. Reads for blocks that have not yet been copied are served from the source image, while writes land in the destination RBD image and the copy process then fills in the rest. The practical cost is contention: the background copy competes with client traffic for network bandwidth, OSD disk time and journal capacity on the Ceph side, so a busy VM can see higher latency during the copy window. Plan the execute window around quiet periods, limit the copy rate where your tooling allows it, and watch OSD latency and slow request warnings in the cluster health output while it runs.
Before you start, confirm how snapshots and backing chains behave for your specific format. A qcow2 image can carry an internal backing chain, and whether a copy preserves, flattens or drops that chain changes what the destination holds and how many reads go back to the source. Check the exact stream and format handling for your release in the Ceph RBD documentation and test with a non-production disk, because the rules differ between raw and qcow2 inputs. Record which snapshots exist on the source, decide whether they must survive the move, and confirm the result with a checksum or sampled read comparison before you rely on it.
Commit is the point of no return for the source. Once you commit, the VM depends solely on the RBD image, so the source file can no longer serve as a fallback without a separate copy. Make sure backups of the source exist and that the restore path is tested before committing. If the threat model requires that traffic between hypervisors and Ceph is protected from eavesdropping or tampering on the network, enable msgr2 secure mode, which encrypts post-authentication traffic with AES-GCM and adds integrity checks. Secure mode adds CPU overhead, so benchmark the copy and the steady-state workload with it enabled. Confirm the configuration in the Ceph messenger v2 documentation for your release.
What drives the cost of importing VM disk images into Ceph RBD
This table lists the factors that change the effort and duration of an RBD image import, whether each factor is paid once or recurs, and what to ask for in a quote. Read it as a checklist: the largest drivers are usually guest write rate, cluster headroom and the allowed commit window, and each one should appear in the written scope.
| Driver | Why it changes effort | One-time or recurring | What to request in a quote |
|---|---|---|---|
| Number and size of disks | Each disk is a separate image to prepare, copy, verify and commit, and total copy time grows with capacity moved. | One-time | Per-VM disk inventory with virtual size, used size and sequencing plan |
| Format complexity | Backing chains, internal snapshots and sparse or thin layouts need flattening or careful stream handling before the copy is trustworthy. | One-time | Format survey of each image, including backing files and snapshots |
| Cluster headroom | Dedicated drives per OSD, WAL and DB on shared SSDs for HDD-based OSDs and bonded links set how much import traffic the cluster absorbs. | One-time, then ongoing as the cluster grows | Capacity and performance check against the Ceph hardware recommendations before import starts |
| Network path | Bandwidth between hypervisors and the Ceph public network limits copy throughput and can slow guest I/O during the live copy. | One-time | Measured throughput between each hypervisor and the public network |
| Guest write rate | A busy guest produces changes faster than the copy can settle, which lengthens the window before commit is safe. | One-time per import wave | Write profile for each VM, taken over a representative period |
| Allowed commit window | A short window forces slower copies or smaller batches, and a missed window means a rollback or a second pass. | One-time per wave | Agreed window per workload and the rollback rule if it is missed |
| Guest driver readiness | Guests without current virtio or disk drivers may need reboots, driver installs or testing before cutover. | One-time per guest OS | Driver check list per operating system and who performs the change |
| Ceph release in use | Support and backports follow the release lifecycle, so an import onto a release near end of life may require an upgrade first. Squid's listed estimated end of life is October 31, 2026, and Tentacle's is June 1, 2027 (per the Ceph releases page). | Recurring until the release is upgraded | Confirmed release, its listed end-of-life date and any upgrade planned before import |
| Ongoing operations after import | Monitoring, capacity growth and patching of the cluster continue after the VMs move and add recurring effort. | Recurring | Whether support, monitoring and patch windows are included or priced separately |
What usually goes wrong when moving VM disks onto Ceph RBD
Most failed VM disk imports come from a small set of predictable causes: copy traffic competing with guest I/O, undersized cluster resources, disk layouts that do not survive conversion, cutover windows that slip, and Ceph releases that age out during the project. Each card below names the risk and the check that prevents it before the first VM is moved.
Copy traffic saturating client I/O
The import reads from the source datastore and writes into RBD at the same time that production VMs are issuing their own reads and writes. If the copy is unthrottled, guest latency climbs and applications time out before anyone sees a Ceph alert. Prevent this by limiting import concurrency and bandwidth, scheduling large copies outside peak hours, and measuring client latency on the pool during a pilot VM before running more imports in parallel. Confirm the throttle options your Ceph and client versions support.
Memory and capacity sized for calm periods
A cluster that handles steady state well can run out of memory or space during recovery, backfill or a burst of imports. The Ceph hardware recommendations advise sizing memory for peak use and benchmarking before buying, because no two clusters are alike. Prevent this by modeling the imported capacity plus replication overhead, leaving headroom for a failed host to recover, and checking OSD memory during the largest test import. Ask your hardware vendor to confirm these figures against your own benchmark.
Backing chains and snapshots not carrying over
A qcow2 file can depend on a backing file, and some snapshots exist only inside the source format. If the import copies only the top layer or flattens chains differently than expected, the guest may boot with missing or stale data. Prevent this by inventorying each disk's backing chain and snapshots before preparing the migration, deciding which snapshots must survive, and comparing checksums or a guest-level test read after commit. Confirm the exact formats and snapshot handling in the RBD import documentation for your release.
Commit missed or delayed past the window
The import runs while the VM stays up, and a final commit step switches the guest to the RBD target. If the delta is larger than expected or the commit waits on a stalled job, the change window closes with the VM still running on the old disk. Prevent this by rehearsing prepare, execute and commit on a non-critical VM, timing the final delta on production-sized disks, and setting a rollback point with a named owner who decides when to abort.
Guest device naming changes breaking boot
Moving a disk can change the device path or bus type the guest sees, for example from one virtio controller to another. Fstab entries, bootloader references and application configs that use device names then fail on the next reboot. Prevent this by referencing filesystems by UUID or label, checking the bootloader and initramfs on a cloned test VM, and keeping the original disk attached but detached from the boot order until the first successful reboot.
Ceph release nearing end of life
A migration that runs for months can finish on a Ceph release that is close to its end of life, which leaves less time for security fixes and forces an upgrade soon after cutover. The Ceph releases page lists an estimated end of life for each active release, and the Squid line carries an earlier date than Tentacle. Prevent this by checking the release calendar at project start, choosing a release with enough support runway for the planned operating period, and scheduling the upgrade path before the first VM moves.
Questions buyers ask before importing VM disks into Ceph RBD
What drives the cost of importing VM disks into Ceph RBD?
Cost follows the number and size of the disks, the source formats, how much data changes while it copies, and how many cutovers you need. The main components are planning and inventory, readiness work on the Ceph target (networks, pools and failure domains), the import runs, validation of each guest, and handover. Recurring cost is limited to any support you keep after cutover. Costs rise when guests have no usable maintenance window, when guest operating systems are unusual, or when the Ceph cluster still needs hardware or network work. Ask for a quote that itemizes these components, lists the number of VMs with provisioned and used capacity, and defines the acceptance test for each guest. DeployOpen quotes follow the written scope.
How long does it take to import VM disks into Ceph?
Duration depends on how much data must cross the network, how quickly the source storage and the Ceph cluster can absorb writes, and how many guests can move in each window. No duration applies to every environment, so ask for a schedule with milestones for each wave and the assumptions behind it. The main drivers are used capacity rather than provisioned size, the change rate of active disks, the time needed for validation, and the time needed to plan rollback. The Ceph hardware recommendations advise benchmarking before buying because no two clusters are alike, so benchmark the source network and the cluster first. A pilot wave of a few non-critical guests gives the most useful figures for the remaining waves.
Does the virtual machine have to stop during the import?
The approach in scope is an RBD import-only live migration, where the VM keeps running while data copies. Cutover happens at the commit step, after the prepare and execute steps, and it usually causes a short interruption while the guest is switched to the new disk. Confirm the exact behavior for your hypervisor and guest, including whether a detach, pause or reboot is needed, against the Ceph RBD documentation for your release and a test on a cloned VM. Heavy write workloads may need a quiet period at commit. Databases should be quiesced or checked for crash consistency. Keep a rollback path in place until validation is signed off.
What must our team provide before an RBD disk import starts?
Provide an inventory, access and approved windows. The inventory lists each VM, its disks, source format (qcow2 or raw), provisioned and used capacity, guest operating system, owner and dependencies. Hypervisor access means an account that can read the disk paths, stream or export data, change VM configuration and open the console for validation. Network work includes an agreed path between the source storage, the hypervisor and the Ceph public and cluster networks, with any bandwidth limits documented. Ceph access needs rights to create pools and images, plus a test VM. Maintenance windows should have named dates, rollback thresholds and change approvals. Incomplete inventories are a common cause of delay, so make it the first deliverable.
Can an internal team import VM disks into Ceph alone?
Often yes, for a pilot, if the team has Ceph operations experience, a rehearsed runbook and a tested rollback. Teams that already run cephadm-managed clusters and have handled RBD images, snapshots and hypervisor storage settings can usually carry out one low-risk wave themselves. The greater risk is the first production cutover, where one wrong step can affect several guests. Assess skills against the prepare, execute and commit steps, the Ceph health checks you will watch, and who signs off on each wave. Many organizations pair internal staff with an outside engineer for the first production wave and then take over the rest. Plan for skills in Ceph health troubleshooting, hypervisor storage configuration and guest recovery.
How is a fixed-scope Ceph disk import engagement agreed?
A fixed-scope engagement is agreed in writing before work starts. DeployOpen agrees the scope, deliverables and timelines first, and the quote follows from that written scope. The scope should name the source hypervisor and storage, the Ceph release and cluster, the VMs and disks that move, the validation that counts as accepted, the cutover windows, and the action taken if a guest fails validation. Deliverables usually include the inventory, runbooks, wave plans, validation records and a handover. Ongoing support and upgrades are separate retainers. Before signing, ask for the assumptions list and acceptance criteria, and ask how changes to scope are documented and priced.
Which Ceph release should the target cluster run?
Choose a release that is still actively maintained when the migration is planned. According to the Ceph releases page, Tentacle (20.2.x) and Squid (19.2.x) are the actively maintained releases, and the page states that they receive periodic backports and security fixes. The estimated end-of-life dates are June 1, 2027 for Tentacle and October 31, 2026 for Squid, so compare them with your cutover and support horizon. Confirm that the RBD import features and stream types you need are supported in the chosen release. If the existing cluster is on an older release, a major upgrade may need to come first, which adds scope and a separate window. Check the release notes with your team before fixing the target.
How DeployOpen scopes and runs a Ceph VM disk import
DeployOpen plans and runs VM disk imports into Ceph RBD inside your own data centers or cloud accounts. We start from a written scope that names every source disk, format, target pool and cutover window, then build, test and document the import so your team can run it again or extend it.
How we scope
- Inventory every source disk, its format, size, guest OS and the VM it belongs to
- Agree in writing which VMs run during copy and which need a planned stop
- Define target pools, image features, cache settings and the rollback point before work starts
How we build
- Prepare the import-only live migration source and target and test the stream on a non-production VM
- Run the execute step against cloned images first and record copy throughput and guest behavior
- Validate each migrated disk with checksums or guest-level checks before the commit step
How we hand over
- Document the prepare, execute and commit runbook with the exact commands used in your environment
- Deliver rollback steps, cutover checklists and a record of which disks moved and when
- Walk your operators through the import path so the team can repeat it for remaining VMs
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer
- Confirm with us during scoping which Ceph release and client versions your import depends on
