8:54 p.m.
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).
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