Migrating linked clones - does that go well?

[William Edwards]

I'm migrating some VMs to different storage. Some of those VMs are linked clones, the parent of which would still be on the old storage.

Should this go well? I tried this in a lab environment, and it looks like the linked clone is converted to a full clone (?), although the disk name format diverges from original full clones, but that seems to be semantic only:

scsi0: local:105/vm-105-disk-0.qcow2,iothread=1,size=32G
(Migrated)

scsi0: local-zfs:vm-227-disk-0,iothread=1,size=32G
(Original full clone)

scsi0: local-zfs:base-103-disk-0/vm-231-disk-0,iothread=1,size=32G
(Linked clone)

 

[bbgeek17]

Hi @William Edwards ,

It looks like your new storage is "local" directory type storage. The old one is "ZFS block" type storage. The name changes are not semantic - they are completely different formats.

There is also no way for you to preserve clone'ness and thin'ness of the original disk. This can only be done for homogeneous storage with storage-native tools, not via host copy.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[William Edwards]

Hi @bbgeek17,

I was moreso referring to the VM ID as prefix (`105/`).

ZFS to local is just for testing purposes. Real migration will be Ceph to Ceph.

Regarding the linked-clone-ness: I'm completely fine with VM disks being converted to full clones. In fact, it has my preference; creating linked clones is a very, very old way of working for us. Just need to know whether converting to a full-clone is indeed how this works, migrating a child image to different storage

 

[bbgeek17]

Just need to know whether converting to a full-clone is indeed how this works, migrating a child image to different storage

Migration across heterogeneous storage is handled by a client-side process. The client has no awareness of the internal layout or implementation details of the virtual disk - it simply reads logical data blocks. Whether those blocks originate from a base image, snapshot chain, clone hierarchy, or fully independent allocation is entirely up to the source storage subsystem to resolve.

There may be optimizations on the client or target side for handling zeroed blocks, sparse regions, etc., but those are unrelated to whether the source disk itself is clone-based.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[William Edwards]

Got it.

Just created a qcow2 image from scratch; can confirm that 'VM ID prefix' is always there, so not specific to my case.

Thanks @bbgeek17!