7:57 p.m.
On Thu, Jan 17, 2019 at 7:54 PM Arik Hadas <ahadas(a)redhat.com> wrote:
On Thu, Jan 17, 2019 at 6:54 PM Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
> On Thu, Jan 17, 2019 at 5:42 PM Gianluca Cecchi <
> gianluca.cecchi(a)gmail.com> wrote:
>
>> On Thu, Jan 17, 2019 at 4:47 PM Gianluca Cecchi <
>> gianluca.cecchi(a)gmail.com> wrote:
>>
>>> On Thu, Jan 17, 2019 at 4:24 PM Arik Hadas <ahadas(a)redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 17, 2019 at 4:53 PM Gianluca Cecchi <
>>>> gianluca.cecchi(a)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:
>>>
>>>
https://ovirt.org/develop/release-management/features/virt/enhance-import...
>>>
>>
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
>
>
>