11:26 a.m.
Hi Nir
In a case of recovery here are the steps we intend to do
--First create an empty disk with the desired disk format ( RAW/COW)
--Then upload the backup image contents within it using the image transfer APIs.
--Attach the disk to the created VM.
During the 2nd step, if it happens to be a QCOW disk, how can we upload the backup image
contents and lay it down in a QCOW2 format. Or does the image transfer API for upload
handles it internally ?
Just wanted to ensure if we need to do anything post upload for QCOW?
Kindly confirm.
-Suchitra
From: Nir Soffer <nsoffer(a)redhat.com>
Date: Friday, November 2, 2018 at 8:12 PM
To: Mahesh Falmari <Mahesh.Falmari(a)veritas.com>, Ryan Barry
<rbarry(a)redhat.com>
Cc: Arik Hadas <ahadas(a)redhat.com>, Martin Perina <mperina(a)redhat.com>,
"Yaniv Lavi (Dary)" <ylavi(a)redhat.com>, Daniel Erez
<derez(a)redhat.com>, "Nisan, Tal" <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: Re: [EXTERNAL] Re: List of Queries related to RHV
On Fri, Nov 2, 2018 at 3:22 PM Mahesh Falmari
<Mahesh.Falmari@veritas.com<mailto:Mahesh.Falmari@veritas.com>> wrote:
Thanks Nir for the answers.
Just a follow up question to your answer on Q.3>
[Nir] 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.
[Mahesh] We are looking for VM version information to be stored during backup for
different reasons. One of the reason is in order to determine the compatibility of VM
backed up from the latest version of RHV server and getting restored to the older
versions.
Trying to restore VM on older version sound fragile. Even if this works,
I don't think we test such scenarios, so this is likely to break in future
versions.
Also, when you say vm configuration, what specific APIs could be leveraged to get it?
Still looking for answer to whether VM version information will be available or not.
I hope that Ryan to help with this.
Thanks & Regards,
Mahesh Falmari
From: Nir Soffer <nsoffer@redhat.com<mailto:nsoffer@redhat.com>>
Sent: Friday, November 2, 2018 1:01 AM
To: Mahesh Falmari
<Mahesh.Falmari@veritas.com<mailto:Mahesh.Falmari@veritas.com>>; Arik Hadas
<ahadas@redhat.com<mailto:ahadas@redhat.com>>; Martin Perina
<mperina@redhat.com<mailto:mperina@redhat.com>>
Cc: Yaniv Lavi (Dary) <ylavi@redhat.com<mailto:ylavi@redhat.com>>; Daniel Erez
<derez@redhat.com<mailto:derez@redhat.com>>; Nisan, Tal
<tnisan@redhat.com<mailto:tnisan@redhat.com>>; Pavan Chavva
<pchavva@redhat.com<mailto:pchavva@redhat.com>>; devel
<devel@ovirt.org<mailto:devel@ovirt.org>>; James Olson
<James.Olson@veritas.com<mailto:James.Olson@veritas.com>>; Navin Tah
<Navin.Tah@veritas.com<mailto:Navin.Tah@veritas.com>>; Sudhakar Paulzagade
<Sudhakar.Paulzagade@veritas.com<mailto:Sudhakar.Paulzagade@veritas.com>>;
Abhay Marode <Abhay.Marode@veritas.com<mailto:Abhay.Marode@veritas.com>>;
Suchitra Herwadkar
<Suchitra.Herwadkar@veritas.com<mailto:Suchitra.Herwadkar@veritas.com>>;
Nirmalya Sirkar
<Nirmalya.Sirkar@veritas.com<mailto:Nirmalya.Sirkar@veritas.com>>; Abhijeet
Barve <Abhijeet.Barve@veritas.com<mailto:Abhijeet.Barve@veritas.com>>
Subject: Re: [EXTERNAL] Re: List of Queries related to RHV
On Wed, Oct 17, 2018 at 5:03 PM Mahesh Falmari
<Mahesh.Falmari@veritas.com<mailto:Mahesh.Falmari@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@redhat.com<mailto:ylavi@redhat.com>>
Sent: Tuesday, October 16, 2018 7:19 PM
To: Mahesh Falmari
<Mahesh.Falmari@veritas.com<mailto:Mahesh.Falmari@veritas.com>>
Cc: Nir Soffer <nsoffer@redhat.com<mailto:nsoffer@redhat.com>>; Erez, Daniel
<derez@redhat.com<mailto:derez@redhat.com>>; Tal Nisan
<tnisan@redhat.com<mailto:tnisan@redhat.com>>; Pavan Chavva
<pchavva@redhat.com<mailto:pchavva@redhat.com>>; devel
<devel@ovirt.org<mailto:devel@ovirt.org>>; James Olson
<James.Olson@veritas.com<mailto:James.Olson@veritas.com>>; Navin Tah
<Navin.Tah@veritas.com<mailto:Navin.Tah@veritas.com>>; Sudhakar Paulzagade
<Sudhakar.Paulzagade@veritas.com<mailto:Sudhakar.Paulzagade@veritas.com>>;
Abhay Marode <Abhay.Marode@veritas.com<mailto:Abhay.Marode@veritas.com>>;
Suchitra Herwadkar
<Suchitra.Herwadkar@veritas.com<mailto:Suchitra.Herwadkar@veritas.com>>;
Nirmalya Sirkar
<Nirmalya.Sirkar@veritas.com<mailto:Nirmalya.Sirkar@veritas.com>>; Abhijeet
Barve <Abhijeet.Barve@veritas.com<mailto:Abhijeet.Barve@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@redhat.com<mailto:ylavi@redhat.com> T:
+972-9-7692306<tel:+972-9-7692306>/8272306<tel:8272306> F:
+972-9-7692223<tel:+972-9-7692223> IM: ylavi
[Image removed by sender.]<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@veritas.com<mailto:Mahesh.Falmari@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