[BACKUP] Estimating qcow2 disk image size before upload
by Nir Soffer
When uploading to qcow2 disks on block storage you must set the disk
initial_size
correctly so the system allocates big enough disk. If the initial size is
too small, the
upload will fail when trying to write after the end of the device.
This info can be useful for people working on a backup solution for oVirt.
The easiest case is upload of existing qcow2 image using the SDK. In this
case we
create a new disk with:
initial_size=image_size,
provisioned_size=virtual_size,
image_size is the size of the file:
os.stat('image').st_size
Note that "qemu-img info" return "actual-size" - this is the allocated size
on storage
which is not helpful for uploading images.
Example:
https://github.com/oVirt/ovirt-engine-sdk/blob/78c3d5bd14eeb93ef72ec31d77...
A more tricky case is when a backup system keeps raw guest data, but know
how
to generate qcow2 image stream, without creating a temporary image.
In this case the required size can be calculated by counting the number of
clusters that need to be allocated in the final image. This depends on the
location of the data in the image.
For example this creates 1G image with only one cluster:
$ python -c 'with open("one-cluster.raw", "wb") as f:
f.truncate(1024**3)
f.write("x")'
$ ls -lhs one-cluster.raw
4.0K -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:24 one-cluster.raw
$ qemu-img measure -f raw -O qcow2 one-cluster.raw
required size: 458752
fully allocated size: 1074135040
$ qemu-img convert -f raw -O qcow2 one-cluster.raw one-cluster.qcow2
$ ls -lhs one-cluster.qcow2
324K -rw-r--r--. 1 nsoffer nsoffer 384K Nov 15 18:25 one-cluster.qcow2
But this creates a fully allocated 1G image:
$ python -c 'with open("fully-allocated.raw", "wb") as f:
f.truncate(1024**3)
for i in range(0, 1024**3, 64 * 1024):
f.seek(i)
f.write("x")'
$ ls -lhs fully-allocated.raw
64M -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:30 fully-allocated.raw
$ qemu-img measure -f raw -O qcow2 fully-allocated.raw
required size: 1074135040
fully allocated size: 1074135040
$ qemu-img convert -f raw -O qcow2 fully-allocated.raw fully-allocated.qcow2
$ ls -lhs fully-allocated.qcow2
1.1G -rw-r--r--. 1 nsoffer nsoffer 1.1G Nov 15 18:31 fully-allocated.qcow2
We had code in vdsm that does exactly this, and it was removed since
qemu-img
support a new "measure" command in RHEL 7.5 providing this info. But this
works
only for existing images.
You can find the code in this vdsm commit:
https://github.com/oVirt/vdsm/tree/4eee97d6aa532b6f3ecdfde0333d17c27c412f86
The module implementing estimation:
https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f...
The tests for this module:
https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f...
If you know the data ranges that will be written to the qcow2 image, you
can count
the clusters like this:
https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f...
Then you can use the cluster count to estimate qcow2 file size:
https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f...
Nir
2 years, 6 months
[Ovirt] [CQ weekly status] [16-11-2018]
by Dafna Ron
Hi All,
I want to just give a quick and simple status on CQ so that everyone is
informed on the general state of our tests when they come in on beginning
of the week.
*Ovirt-Master*- *GREEN*
*Ovirt-4.2* -
*GREEN*
Happy Week!
Dafna
2 years, 6 months
Re: [EXTERNAL] Re: List of Queries related to RHV
by Nir Soffer
On Wed, Oct 17, 2018 at 5:03 PM Mahesh Falmari <Mahesh.Falmari(a)veritas.com>
wrote:
> Thanks for the prompt response on these queries. We have few follow-up
> queries mentioned inline.
>
>
>
> Thanks & Regards,
> Mahesh Falmari
>
>
>
> *From:* Yaniv Lavi <ylavi(a)redhat.com>
> *Sent:* Tuesday, October 16, 2018 7:19 PM
> *To:* Mahesh Falmari <Mahesh.Falmari(a)veritas.com>
> *Cc:* Nir Soffer <nsoffer(a)redhat.com>; Erez, Daniel <derez(a)redhat.com>;
> Tal Nisan <tnisan(a)redhat.com>; Pavan Chavva <pchavva(a)redhat.com>; devel <
> devel(a)ovirt.org>; James Olson <James.Olson(a)veritas.com>; Navin Tah <
> Navin.Tah(a)veritas.com>; Sudhakar Paulzagade <
> Sudhakar.Paulzagade(a)veritas.com>; Abhay Marode <Abhay.Marode(a)veritas.com>;
> Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com>; Nirmalya Sirkar <
> Nirmalya.Sirkar(a)veritas.com>; Abhijeet Barve <Abhijeet.Barve(a)veritas.com>
> *Subject:* [EXTERNAL] Re: List of Queries related to RHV
>
>
>
>
> *YANIV LAVI*
>
> SENIOR TECHNICAL PRODUCT MANAGER
>
> Red Hat Israel Ltd. <https://www.redhat.com/>
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> ylavi(a)redhat.com T: +972-9-7692306/8272306 F: +972-9-7692223
> IM: ylavi
>
> <https://red.ht/sig>
>
> *TRIED. TESTED. TRUSTED.* <https://redhat.com/trusted>
>
> @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc>
>
>
>
> On Tue, Oct 16, 2018 at 4:35 PM Mahesh Falmari <Mahesh.Falmari(a)veritas.com>
> wrote:
>
> Hi Nir,
>
> We have few queries with respect to RHV which we would like to understand
> from you.
>
>
>
> *1. Does RHV maintains the virtual machine configuration file in back end?*
>
> Just like we have configuration files for other hypervisors like for
> VMware it is .vmx and for Hyper-V, it is .vmcx which captures most of the
> virtual machine configuration information in that. On the similar lines,
> does RHV also maintains such file? If not, what is the other way to get all
> the virtual machine configuration information from a single API?
>
>
>
> There is a OVF storage, but this is not meant for consumption.
>
Right, this is only for internal use.
...
> *3. Do we have any version associated with the virtual machine?*
>
> Just like we have hardware version in case of VMware and virtual machine
> version in case of Hyper-V, does RHV also associate any such version with
> virtual machine?
>
>
>
> The HW version is based on the VM machine type.
>
> [Mahesh] Can you please elaborate more on this? How simply VM machine
> type going to determine it’s version?
>
Arik, can you answer this?
Regarding backup, I think you need to store the vm configuration at the
time of the
backup regardless of having a version or not. The amount of data is very
small.
> *4. Is it possible to create virtual machines with QCOW2 as base disks
> instead of RAW?*
>
> We would like to understand if there are any use cases customers prefer
> creating virtual machines from QCOW2 as base disks instead of RAW ones.
>
>
>
> That is a possibility in cases of thin disk on file storage.
>
> [Mahesh] Can you please elaborate more on this?
>
Using the UI you can use qcow2 format only for thin disks on block storage.
Using the SDK you can also create qcow2 image on thin file based storage.
You can see examples here:
https://github.com/oVirt/ovirt-engine-sdk/blob/78c3d5bd14eeb93ef72ec31d77...
In 4.3 we plan to support qcow2 image format for both thin and preallocated
disks to allow change block tracking for incremental backup. See
html:
https://github.com/oVirt/ovirt-site/blob/bc51f4a7867d9c7e3797da6da1d19e11...
>
>
> *5. RHV Deployment*
>
> What kind of deployments you have come across in the field? Does customers
> scale their infrastructure by adding more datacenters/clusters/nodes or
> they add more RHV managers? What scenarios trigger having more than one RHV
> manager?
>
>
>
> We are all kind with oVirt. I depends on the use case.
>
I don't know about any stats from users, but the general idea is:
- one engine
- 1 or more DCs
- 1 or more storage domains in a DC
- 1 or more clusters per DCs
- 1 or more hosts per cluster
The theoretical limit is 2000 hosts per DC (limited by sanlock), but the
practical
limit is much lower. I don't think we have setups with more than 200 hosts.
Martin, do you have more info on this?
> *6. Image transfer*
>
> We are trying to download disk chunks using multiple threads to improve
> performance of reading data from RHV. Downloading 2 disk chunks
> simultaneously via threads should take approximately the same time.
>
> This is much more complicated to calculate.
> But from our observations this takes roughly 1.5 times.
>
>
It sounds like a reasonable speed up.
Can RHVM server requests in parallel,
>
>
Yes
> if so are there any settings that need to be tweaked?
>
>
We don't have any settings related to concurrency.
> Here is an example:
> Request 1 for chunk 1 from thread 1, Range: bytes=0-1023
> Request 2 for chunk 2 from thread 2, Range: bytes=1024-2047
> Takes roughly 1.5 seconds, whereas a single request would take 1 second.
> Expecting it to take just around 1 second.
>
> 1.5 seconds for reading 1024 bytes?
> [Mahesh] Seeking response to this query.
>
>
The throughout you will get depends on many things:
- are you communicating with the proxy (using proxy_url) or the daemon
(transfer_url)? Accessing the daemon directly will be faster.
- are you running on the same host as the daemon performing the transfer?
- if you run on the same host, are you using unix socket? (15% improvement
expected)
- are you using the same connection per thread for entire transfer (huge
improvement
when doing small requests)
- which version are you testing? we support keep alive connections only
since 1.4.x.
- are you using big enough requests? you will get best performance if you
use one
big request per thread
- network bandwidth
- storage speed
For best throughput when downloading single disk, you should use multiple
threads,
each downloading one part of an image, but I'm not sure it worth the time
to optimize
this since backup are expected the run in the same time anyway, and you
will quickly
reach the storage limit while downloading disks for multiple vms on
multiple hosts
in the same time.
I suggest testing the expected use case, not single download.
> *7. Free and Thaw operation*
>
> For cinder based VM, API recommended for FS consistent backup.
>
> - POST /api/vms/<ID>/freezefilesystems
> - POST /api/vms/<ID>/thawfilesystems
>
> Why do we need this whereas it is not required for other storage?
>
> Creating a snapshot does this for you in a case where you have the oVirt
> guest agent install on the guest.
>
> [Mahesh] Thanks, we would also like to understand is there a way to
> control crash/app consistent snapshots through REST APIs?
>
snapshots are always consistent if you have qemu guest agent installed, and
the
guest is using the guest agent scripts properly.
Without the guest agent, or if it is not configured properly, file system
will have to
recover after restore, in the same way it recovers after power failure.
To be able to resume a vm to the same state when the snapshot was done you
need to include memory in the snapshot, but this make the snapshot much
slower,
depending on the amount of guest memory, and require huge amount of space,
so I don't think it makes sense for backup.
Regarding REST API, Arik can add more info about this.
Nir
2 years, 6 months
Proposing Shmuel Melamud as a Virt backend maintainer
by Michal Skrivanek
Hi all,
I’d like to propose Shmuel as a backend maintainer for the virt area. He’s a good candidate with his 200+ patches and insight into complex parts of VM pools, templates, q35 support, v2v, sparsify...
Feel free to bother him more with review requests;)
Thanks,
michal
2 years, 6 months
Please Stop merging to ovirt-engine master branch
by Dafna Ron
Hi ,
Please stop merging to ovirt-engine master branch as we have been failing
on different regressions for the last 11 days.
I do not want any other regressions to be introduced until we can properly
catch them which means we need to fix the current issues before merging
more changes.
Thanks,
Dafna
2 years, 6 months
VDSM-Gluster python 3 compatibility
by Kaustav Majumder
Hi all,
I have been working on making vdsm-gluster python 3 compatible. I had some
queries regarding the tool used for getting storage devices info. Till now
vdsm uses python blivet for getting the device tree information.
I am not sure if blivet is compatible with python 3 so I had two
propositions which I want some advice on.
1) Using lsblk and parsing the output
2) Using ansible modules locally in the vdsm hosts.
Although I feel the 2nd way will add more dependencies to the project but
it can help us in the long run to add more functionality easily.
Thanks,
Kaustav
2 years, 6 months
