Maybe I overlooked the information, but in recent RHVE 4.3 docs the information how to use the export storage domain have been removed and there is no alternative to do so, but to detach a data domain and attach it somewhere else. But how can I move my VMs one by one to a new storage domain on a different datacenter without completely detaching the original storage domain?
It not clear what do you mean by different datacenter.
The best way to decommission a storage domain is to move the disks to another domain in the same DC.
You can do this while the VM is running, without any downtime. When you are done, you can detach and
remove the old storage domain.
If you want to move the VM to a different storage domain on another oVirt DC, move the domain to the same
DC until you finish the migration, and then move the domain back to another DC and import the VM. If you
want to use the same domain for exporting and importing, you will need to move the VM to another domain
on the target DC.
If you want to move the VM to another oVirt setup, you can attach a temporary storage domain, move the disk
to that storage domain, detach the domain, attach it to the other setup, and import the VM.
If you can replicate the storage using your storage server (e.g, take a snapshot of a LUN), you can
attach the new LUN to the new setup and import the VMs. (this is how oVirt DR works)
If you don't have shared storage between the two setups, maybe different physical datacenters, you can:
- export OVA, and import it on the other setup
- download the vm disks, upload them to the other setup and recreated the vm
To minimize downtime while importing and exporting a VM using attach/detach storage domain:
On the source setup:
1. Attach the temporary storage domain used for moving vms
2. While the VM is running, move the disks to the temporary storage domain
3. Stop the VM
4. Detach the temporary storage domain
On the destination setup:
5. Attach the temporary storage domain to other setup
6. Import the VM
7. Start the VM
8. While the VM is running, move the disks to the target storage domain
Steps 3-7 should take only 2-3 minutes, and do no data operations. Exporting and importing big VMs
using export domain can take many minutes or hours.
This can be automated using oVirt REST API, SDK, or Ansible.
I don't want to bring down all of my VMs on the old storage domain for import. I want to export and import them one by one. When all VMs are moved to the new data center only then I want to decommission
the old data center.
What is the rationale to deprecate the export storage and already remove documentation when there seems to be no alternative available?
There are many alternatives for several versions, listed above. The main alternative is attach/detach
storage domain.
This method has many advantages like:
- If you can keep the VMs on the same storage, requires no data copies, minimizing total time to
move the VMs around.
- If you cannot keep the VMs on same storage, requires up to 2 data copies, like export domain
- But unlike export domain, you can do the copies in the background while the VM is running
(see my example above).
- Does not require NFS storage on your high end iSCSI/FC setup
- Since you can use block storage, more reliable and perform better due of multipath
- Since we use regular data domain, easier to maintain and less likely to break
- Works with any recent storage format (V3, V4, V5), while export domain requires V1. Assuming that
all future version of a product will support all storage formats was never a good idea.
We are playing with a new way to move VM with minimal downtime, using a the concept of "external disk".
With this you will be able to run a tool that will shutdown the VM on one setup, and start it in seconds
on the other setup. While the VM is running, it will migrate the disks from the old storage to new storage.
This method does not require shared storage to be available to both setups, only that we can expose
the source disks over the network, for example using NBD.
There is a proof of concept here:
Nir