Bug 1198507 - [RFE] implement support from sparse file launching the VM from a disk image
Summary: [RFE] implement support from sparse file launching the VM from a disk image
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: RFEs
Version: ---
Hardware: Unspecified
OS: Unspecified
high
low
Target Milestone: ---
: ---
Assignee: Simone Tiraboschi
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks: 1274065
TreeView+ depends on / blocked
 
Reported: 2015-03-04 10:00 UTC by Simone Tiraboschi
Modified: 2016-10-14 14:55 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-14 14:55:19 UTC
oVirt Team: Integration
Embargoed:
ylavi: ovirt-future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

Description Simone Tiraboschi 2015-03-04 10:00:46 UTC
hosted-engine can be deployed launching the engine VM from a disk image: in that case it uploads the image to the new data domain.
Currently it uses python utilities to copy the image file and so it doesn't support sparse image with the result of transfering a lot of '0' over the net. Implementing sparse file support, as we did for image-uploader, we can drastically reduce uploading time.

Comment 1 Simone Tiraboschi 2015-12-10 17:11:31 UTC
The image file in the engine appliance ova archive is already a qcow2 file so it is implicitly sparse.
We use python tar module to extract the qcow2 from the tar archive to a local temporary file.

We are using qemu-img to convert and copy from the temporary qcow2 to a raw image on the shared storage domain.
qemu-img already correctly supports sparse raw images so there is not that much to gain here.

We can just save a bit of time in the tar extraction using external tar command but not that much.

Comment 2 Simone Tiraboschi 2015-12-11 16:49:41 UTC
I also tried to manually apply virt-sysprep and virt-sparsify on our engine appliance without being able to reduce the qcow2 size (perhaps it's already sparsified in the appliance build process) and so no margin neither there.

We can probably just gain a bit of speed in the tar extraction using native tar instead of python one but nothing more.

Probably we could gain something if we are able to pipe qcow2 file to qemu-img to covert and write it on fly to the target device instead of passing trough a temporary file but AFAIK qemu-img doesn't work with stdin.

Comment 3 Simone Tiraboschi 2016-10-14 14:55:19 UTC
Closing as NOTABUG according to https://bugzilla.redhat.com/show_bug.cgi?id=1198507#c1 and https://bugzilla.redhat.com/show_bug.cgi?id=1198507#c2


Note You need to log in before you can comment on or make changes to this bug.