On Thu, Nov 29, 2018 at 4:41 PM Suchitra Herwadkar <
Hi Nir, Pavan
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
will be configured to write direct to the image
- if conversion is needed, RHV will start qemu-nbd process on the upload
and the imageio daemon will be configured with nbd url
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
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
backup. We can support creating full backup using the nbd based pipeline,
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
so we can include the disk in incremental backup.
1. If we use incremental backups, then will there not be a
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