On Thu, Jan 17, 2019 at 7:54 PM Arik Hadas <ahadas@redhat.com> wrote:


On Thu, Jan 17, 2019 at 6:54 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Jan 17, 2019 at 5:42 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Jan 17, 2019 at 4:47 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Jan 17, 2019 at 4:24 PM Arik Hadas <ahadas@redhat.com> wrote:


On Thu, Jan 17, 2019 at 4:53 PM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
Hello,
I have two different oVirt 4.2 environments and I want to migrate some big VMs from one to another. 
I'm not able to detach and attach the block based domain where are the disks of source.
And I cannot use export domain functionality.

you can export them to ova on some device that can later be mounted to the destination environment.
this is similar to the export domain functionality - but you didn't specify why the export domain functionality is not applicable for you.

Ah, ok, thanks. 
I think you are referring to this feature page and I see in my 4.2.7 env I can do it for a powered off VM:

Right
 

I will try
Are the two described TBD features:
- export as ova also a running VM
- stream to export to ovirt-imageio daemon
supposed to be included in 4.3, or is there already a planned target release for them?

The first one is included in 4.3 already (in general, the ova handling is better in 4.3 compared to 4.2 in terms of speed).

I meant to say: in general, the ova handling is better in 4.3 compared to 4.2.
 
The second is unlikely to happen as we found there's no real need for it.
 

Gianluca

BTW: would it be possible to export as ova on a path on host that is an NFS share, bypassing export domain setup, or does it require local storage?

Yes, but note that you need to mount the NFS share in a way that the root user on host can write to the specified path.
 

Gianluca 


 Strange: I tried from the GUI with a vm with 3 disks and specifying a directory but it seems that it has started 3 processes of type "qemu-img convert" where destination is on the storage domain itself???
Does it need this step before writing to the destination I chose? I hope no...

Unfortunately, it is indeed done that way in 4.2 :/
Let me explain:
We wanted disks within the ova to be of type qcow (for several reasons, like thin-provisioning, compression).
In 4.2 we create temporary disks on the storage that are then copied into the OVA (and then removed).
In 4.3 qemu-img converts the images directly into the place they should be within the OVA. That's the reason for the export process being faster in 4.3.
 

vdsm     14380 14269  2 17:33 ?        00:00:14 /usr/bin/qemu-img convert -p -t none -T none -f raw /rhev/data-center/mnt/blockSD/fa33df49-b09d-4f86-9719-ede649542c21/images/8cf79957-1b89-42c6-a7af-8031b22f3771/8846e584-190d-403e-a06a-792cebe3b1b1 -O qcow2 -o compat=1.1 /rhev/data-center/mnt/blockSD/fa33df49-b09d-4f86-9719-ede649542c21/images/8ab058e1-19fd-440a-aa91-c137a79a870e/335c5fdb-025b-4e3e-82a8-06ec9d808d60


Gianluca