[ovirt-devel] Re: List of Queries related to RHV

[Nir Soffer]

On Thu, Nov 29, 2018 at 4:41 PM Suchitra Herwadkar <
suchitra.herwad...@veritas.com> wrote:

> Hi Nir, Pavan
>
>
>
>
> https://ovirt.org/develop/release-management/features/storage/incremental-backup/
>
>
>
> On reading more from the article, we have some questions which we will
> like to discuss in the call
>
>
>
>1. Irrespective of the underlying storage, we will always restore the
>data as raw. But it’s not very clear to us how the disk format conversion
>will be taken care of internally by RHV.
>
>
It works like this:

1. you create a new disk or add a new snapshot

2. you start a transfer with source_format=raw (not final API yet)

3. RHV knows the both the disk format and the source format, so it can
setup the upload to do automatic conversion:

   - If no conversion is needed, RHV can setup direct upload - imageio
daemon
  will be configured to write direct to the image
(file:///rhev/data-center/...)

  - if conversion is needed, RHV will start qemu-nbd process on the upload
host
and the imageio daemon will be configured with nbd url
(nbd:unix:/run/vdsm/nbd/...)

4. RHV returns upload url

5. you upload using the upload url

6. imageio daemon write the data to the either file (data written as is) or
nbd
   (data converted).


>
>1. Conversion from raw data to qcow format will only work for disk
>marked to be incremental or it is not specific to that only.
>
>   Would rhv stage the data before conversion to qcow2.
>

No, we stream data to/from storage or nbd server.


>
>
>1. For this feature( incremental backup) to work, disks have to be
>marked as such. User needs to mark those disks as incrementals while
>creating VM, otherwise this will not work.
>
> The limit is the image format - if a disk is using raw format, we cannot
do incremantl
backup. We can support creating full backup using the nbd based pipeline,
but
this is not planned for the first version supporting incremental backup.

If the user mark the disk for incremental backup, we will always use qcow2
format,
so we can include the disk in incremental backup.


>1. If we use incremental backups, then will there not be a backing
>file. Do we have to upload the entire image and then rhv would convert to
>qcow. What if we want to just upload just the incremental part/changes
>relative to some base image.
>
> You can do this:

1. add a new snapshot
2. determine which data need to be written to disk
3. upload only this data to the snapshot

The user can keep the snapshot, or merge it into the previous snaphost
to "commit" the backup.

If the user want revert the restore, she can preview the previous snapshot
and commit.

Nir
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/I26X3GAEYKBFG4LCZYSIEZLSVGWUTR2U/

[ovirt-devel] Re: List of Queries related to RHV

[Yaniv Lavi]

YANIV LAVI

SENIOR TECHNICAL PRODUCT MANAGER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor

Ra'anana, Israel 4350109

yl...@redhat.comT: +972-9-7692306/8272306 F: +972-9-7692223IM: ylavi
  TRIED. TESTED. TRUSTED. 
@redhatnews    Red Hat
   Red Hat




On Tue, Oct 16, 2018 at 4:35 PM Mahesh Falmari 
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.
Please follow the first section in:
*https://ovirt.org/develop/release-management/features/storage/backup-restore-disk-snapshots/
*
This explains how to use the API to get a OVF for a VM.


>
>
> *2. Is VM UUID the only way to uniquely identify virtual machine in the
> RHV infrastructure?*
>
> What we understand is that VM UUID is the way to identify virtual machine
> uniquely in the RHV infrastructure. Would like to know any other way than
> this?
>

UUID is the way to do this.


>
>
> *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.


>
>
> *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.


>
>
> *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.


>
> *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. But
> from our observations this takes roughly 1.5 times.
> Can RHVM server requests in parallel, if so are there any settings that
> need to be tweaked?
>
> 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.
>
>
>
> *7. Free and Thaw operation*
>
> For cinder based VM, API recommended for FS consistent backup.
>
>- POST /api/vms//freezefilesystems
>- POST /api/vms//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.


>
>
> Thanks & Regards,
> Mahesh Falmari
>
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/OB2TWNFJB6VUCLEZWO2ML6CTONT3NMHK/