I'm hoping someone else has had to do this and either has a script, or can at least point me in the right direction towards making one.

virtctl

or the UI has to have some sort of way to export an image or disk right?

The thing is that most of these OS images on the VMs are cloudinit images that are image backed. I can already flatten them to be standard longhorn images (not image backed), but it would be better to be able to create an exportable/importable image with the PVC

I found this, but it's not immediately obvious to me if the full feature set it in Harvester 1.4.2: https://kubevirt.io/user-guide/storage/export_api/

i wonder if we can extend the

vm-import-controller

to support harvester-to-harvester scenario, since 3rd party csi is a pain atm

the controller is already using the

VirtualMachineExport

api

As I read it, it exports the PVCs as either files in a tar or as a standard qcow/disk image (compressed)

since it's the upstream kubevirt, it doesn't seem to care what the csi driver is doing.

I'm not sure how much time I'll have for this given our current backlog at work.

If I do, I'll be sure to put anything I find out here. 🙂

i don't know if they have done much with vm since i was last there

ok.. seems promising: https://github.com/kubevirt/kubevirt-velero-plugin

backup/restore involves crash consistent snapshotting and data movement to provide a stronger guarantee rto, rpo etc.

from a feature perspective, i see export/import as an one-off

backup is something that you can build a recurring schedule, retention policy, incremental vs. changed block aroud etc.

@bland-article-62755 re: export/import, what kind of workloads are you running on the vm? from my testing with velero, even though i can successfully backup/restore vm, some workloads (like etcd) might not run successfully

I did get a manual migration path figured out

Or a professor wanting to do research with AI or datasets.

Ok, here's the manual steps for exporting/importing vms from one cluster to another: • Stop the VM. • Copy the MAC address from the network interface and make note of cores/RAM. • Go to Volumes and find the disk(s). Export disk to image. • Download the image. • Extract the raw image from the tarbal • convert from raw to qcow (compressed)

qemu-img convert -f raw -O qcow2 -c -p -S 4k ~/Downloads/lti-dev-db ~/Downloads/lti-dev-db.qcow2

• Upload the image to cluster directly (ie from fqdn for the vip on the harvester cluster and not through rancher ) • Create new disk with the image. • Flatten the disk with the pvc-flattener script. (ie

./pvc-disk-flatner lti-dev-db-root canvas lti-dev-db-flat

) • Create a new VM with the flat disk and the MAC from the previous vm. • Verify the VM boots properly. • Delete the Backed Image PVC (you may need to delete the Job and completed pods from the flattening via the embedded rancher UI) • Delete the Imported image.

If we had a block device in another storage class outside of longhorn, we used this other script to migrate it to longhorn so it could be exported.

For some extra context: https://rancher-users.slack.com/archives/C01GKHKAG0K/p1746638856608079?thread_ts=1746636383.667569&cid=C01GKHKAG0K

Do you want me to comment more on the github issue or here?

yeah, i was trying to get the vm image to work, but it's a bit tricky

i velero ended up fighting with kubevirt cdi

BTW overall, I think this is great.

I think that's all I got.

Hope it's helpful!

Sorry freak'n github left my comments on pending until I "published" a review.

yeah, when i looked at the comments timestamp, i thought i missed them yesterday