On Wed, May 15, 2019 at 3:52 PM Andreas Elvers < andreas.elvers+ovirtforum@solutions.work> wrote:
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: https://gerrit.ovirt.org/c/98926/ Nir