On Fri, Nov 2, 2018 at 10:42 AM Nir Soffer <[email protected]> wrote:
> On Fri, Nov 2, 2018 at 3:22 PM Mahesh Falmari <[email protected]> > 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. > @Ryan Barry <[email protected]> Can you provide more feedback about this? Thanks, Pavan. > > >> >> >> Thanks & Regards, >> Mahesh Falmari >> >> >> >> *From:* Nir Soffer <[email protected]> >> *Sent:* Friday, November 2, 2018 1:01 AM >> *To:* Mahesh Falmari <[email protected]>; Arik Hadas < >> [email protected]>; Martin Perina <[email protected]> >> *Cc:* Yaniv Lavi (Dary) <[email protected]>; Daniel Erez <[email protected]>; >> Nisan, Tal <[email protected]>; Pavan Chavva <[email protected]>; devel >> <[email protected]>; James Olson <[email protected]>; Navin Tah < >> [email protected]>; Sudhakar Paulzagade < >> [email protected]>; Abhay Marode <[email protected]>; >> Suchitra Herwadkar <[email protected]>; Nirmalya Sirkar < >> [email protected]>; Abhijeet Barve <[email protected]> >> *Subject:* Re: [EXTERNAL] Re: List of Queries related to RHV >> >> >> >> On Wed, Oct 17, 2018 at 5:03 PM Mahesh Falmari < >> [email protected]> wrote: >> >> Thanks for the prompt response on these queries. We have few follow-up >> queries mentioned inline. >> >> >> >> Thanks & Regards, >> Mahesh Falmari >> >> >> >> *From:* Yaniv Lavi <[email protected]> >> *Sent:* Tuesday, October 16, 2018 7:19 PM >> *To:* Mahesh Falmari <[email protected]> >> *Cc:* Nir Soffer <[email protected]>; Erez, Daniel <[email protected]>; >> Tal Nisan <[email protected]>; Pavan Chavva <[email protected]>; devel < >> [email protected]>; James Olson <[email protected]>; Navin Tah < >> [email protected]>; Sudhakar Paulzagade < >> [email protected]>; Abhay Marode <[email protected]>; >> Suchitra Herwadkar <[email protected]>; Nirmalya Sirkar < >> [email protected]>; Abhijeet Barve <[email protected]> >> *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 >> >> [email protected] 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 < >> [email protected]> 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/78c3d5bd14eeb93ef72ec31d775ff5c41f51a8c7/sdk/examples/upload_disk.py#L123 >> >> >> >> 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/bc51f4a7867d9c7e3797da6da1d19e111cd2ff67/source/develop/release-management/features/storage/incremental-backup.html.md >> >> >> >> *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 >> > -- PAVAN KUMAR CHAVVA ENGINEERING PARTNER MANAGER Red Hat [email protected] M: 4793219099 IM: pchavva
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/GIJ44BXFJTBD4JGI5JKZMWUL52B6XJXC/
