[SOLVED] cephFS , can we some how force allow Vm image for QM-REMOTE-MIGRATE purpose?

[DC-CA1]

senario.

we want to move VM from SHARED SAS storage on CLUSTER1 to RBD on CLUSTER2

the vm image on cluster1 are Qcow2, i get a error saying RBD is not supported.

my only solution is to use a tmp file system from ceph and move the vm there at step 1 and switch them on RBD at step 2

but proxmox do not allow me to enable Vm image, even if i forced it in /etc/pve/storage.conf , i have same error saying cephfs traget do not support image.

based on my research back in 2015 people was able to have VM with qcow2 on cephFS

thx for advices

 

[gurubert]

Do you have your shared SAS storage configured in Proxmox?
Do you have an RBD pool as storage in Proxmox?

Then you should be able to migrate the VM disk via the GUI.

 

[DC-CA1]

Hi sorry I was referring to qm-remote-migrate.

We can't do qcow2 file to RBD block with the qm remote . It always fail as unsupported. Even if it work from the same cluster when moving disk.

So I need to send the qcow2 to another filesystem and vmdisk seem disabled in cephfs and it's the only storage type I have in this new cluster...

 

[DC-CA1]

Hi sorry I was referring to qm-remote-migrate.

We can't do qcow2 file to RBD block with the qm remote . It always fail as unsupported. Even if it work from the same cluster when moving disk.

So I need to send the qcow2 to another filesystem and vmdisk seem disabled in cephfs and it's the only storage type except the RBD pool in this new cluster...

 

[Falk R.]

The easiest way is Backup and Restore.
You can also add the RBD to the old cluster and made live migrate Disks.

 

[DC-CA1]

is there a way to Enable VM image on a cephFS pool ? @fabian

 

[fabian]

you can define a directory storage that actually sits on top of CephFS - but we plan on extending the volume export/import code to also support rbd storages.

 

[DC-CA1]

you can define a directory storage that actually sits on top of CephFS - but we plan on extending the volume export/import code to also support rbd storages.

worked like charm thx.
question: is it normal that that each successfuly live migrated VM , left the old one in a lock migrate state ?

this appened on each of my test and migration task job report OK ( no error )

 

[fabian]

yes, the feature is still experimental so this is kind of a safeguard in case there are still bugs lurking. you can bypass it by setting "--delete", then the source VM will be cleaned up after a successful migration.

 

[DC-CA1]

thank you fabian for the answers

 

[igor449]

you can define a directory storage that actually sits on top of CephFS - but we plan on extending the volume export/import code to also support rbd storages.

I use a workaround. Instead of doing a direct qm/pct remote-migrate to the ceph storage, copy the VM to another storage (like local storage), then migrate from local to the ceph (just remember to select the option to destroy the virtual disk from the local sotage at the web UI, or you will have to remove it using the terminal as it has the same VMID as an existing VM/QT).

Also, as the remote-migrate doesn't remove the VM/QT from the origin by default it should be safe do to a local storage. Just check if you have enough space at the storage for the virtual disk and you'll be good to go.

Sorry to answer to a one year old and solved post, but I would like to share my solution.