<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 11:32 AM, Luca 'remix_tj' Lorenzetto <span dir="ltr"><<a href="mailto:lorenzetto.luca@gmail.com" target="_blank">lorenzetto.luca@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On Mon, Feb 5, 2018 at 7:20 PM, Maor Lipchuk <<a href="mailto:mlipchuk@redhat.com">mlipchuk@redhat.com</a>> wrote:<br>
> Hi Luca,<br>
><br>
> Thank you for your interst in the Disaster Recovery ansible solution, it is<br>
> great to see users get familiar with it.<br>
> Please see my comments inline<br>
><br>
> Regards,<br>
> Maor<br>
><br>
> On Mon, Feb 5, 2018 at 7:54 PM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Feb 5, 2018 5:00 PM, "Luca 'remix_tj' Lorenzetto"<br>
>> <<a href="mailto:lorenzetto.luca@gmail.com">lorenzetto.luca@gmail.com</a>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> i'm starting the implementation of our disaster recovery site with RHV<br>
>> 4.1.latest for our production environment.<br>
>><br>
>> Our production setup is very easy, with self hosted engine on dc<br>
>> KVMPDCA, and virtual machines both in KVMPDCA and KVMPD dcs. All our<br>
>> setup has an FC storage backend, which is EMC VPLEX/VMAX in KVMPDCA<br>
>> and EMC VNX8000. Both storage arrays supports replication via their<br>
>> own replication protocols (SRDF, MirrorView), so we'd like to delegate<br>
>> to them the replication of data to the remote site, which is located<br>
>> on another remote datacenter.<br>
>><br>
>> In KVMPD DC we have some storage domains that contains non critical<br>
>> VMs, which we don't want to replicate to remote site (in case of<br>
>> failure they have a low priority and will be restored from a backup).<br>
>> In our setup we won't replicate them, so will be not available for<br>
>> attachment on remote site. Can be this be an issue? Do we require to<br>
>> replicate everything?<br>
><br>
><br>
> No, it is not required to replicate everything.<br>
> If there are no disks on those storage domains that attached to your<br>
> critical VMs/Templates you don't have to use them as part of yout mapping<br>
> var file<br>
><br>
<br>
</div></div>Excellent.<br>
<span class="gmail-"><br>
>><br>
>> What about master domain? Do i require that the master storage domain<br>
>> stays on a replicated volume or can be any of the available ones?<br>
><br>
><br>
><br>
> You can choose which storage domains you want to recover.<br>
> Basically, if a storage domain is indicated as "master" in the mapping var<br>
> file then it should be attached first to the Data Center.<br>
> If your secondary setup already contains a master storage domain which you<br>
> dont care to replicate and recover, then you can configure your mapping var<br>
> file to only attach regular storage domains, simply indicate<br>
> "dr_master_domain: False" in the dr_import_storages for all the storage<br>
> domains. (You can contact me on IRC if you need some guidance with it)<br>
><br>
<br>
</span>Good,<br>
<br>
that's my case. I don't need a new master domain on remote side,<br>
because is an already up and running setup where i want to attach<br>
replicated storage and run the critical VMs.<br>
<span class="gmail-"><br>
<br>
<br>
>><br>
>><br>
>> I've seen that since 4.1 there's an API for updating OVF_STORE disks.<br>
>> Do we require to invoke it with a frequency that is the compatible<br>
>> with the replication frequency on storage side.<br>
><br>
><br>
><br>
> No, you don't have to use the update OVF_STORE disk for replication.<br>
> The OVF_STORE disk is being updated every 60 minutes (The default<br>
> configuration value),<br>
><br>
<br>
</span>What i need is that informations about vms is replicated to the remote<br>
site with disk.<br>
In an older test i had the issue that disks were replicated to remote<br>
site, but vm configuration not!<br>
I've found disks in the "Disk" tab of storage domain, but nothing on VM Import.<br></blockquote><div><br></div><div><br></div><div>Can you reproduce it and attach the logs of the setup before the disaster and after the recovery?</div><div>That could happen in case of new created VMs and Templates which were not yet updated in the OVF_STORE disk, since the OVF_STORE update process was not running yet before the disaster.</div><div>Since the time of a disaster can't be anticipated, gaps like this might happen.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
>><br>
>> We set at the moment<br>
>> RPO to 1hr (even if planned RPO requires 2hrs). Does OVF_STORE gets<br>
>> updated with the required frequency?<br>
><br>
><br>
><br>
> OVF_STORE disk is being updated every 60 minutes but keep in mind that the<br>
> OVF_STORE is being updated internally in the engine so it might not be<br>
> synced with the RPO which you configured.<br>
> If I understood correctly, then you are right by indicating that the data of<br>
> the storage domain will be synced at approximatly 2 hours = RPO of 1hr +<br>
> OVF_STORE update of 1hr<br>
><br>
<br>
</span>We require that we can recover vms with a status that is up to 2 hours<br>
ago. In worst case, from what you say, i think we'll be able to.<br>
<br>
[cut]<br>
<span class="gmail-">><br>
> Indeed,<br>
> We also introduced several functionalities like detach of master storage<br>
> domain , and attach of "dirty" master storage domain which are depndant on<br>
> the failover process, so unfortunatly to support a full recovery process you<br>
> will need oVirt 4.2 env.<br>
><br>
<br>
</span>Ok, but if i keep master storage domain on a non replicate volume, do<br>
i require this function?<br></blockquote><div><br></div><div><br></div><div>Basically it should also fail on VM/Template registration in oVirt 4.1 since there are also other functionalities like mapping of OVF attributes which was added on VM/Templates registeration.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I have to admit that i require, for subscription and support<br>
requirements, to use RHV over oVirt. I've seen 4.2 is coming also from<br>
that side, and we'll upgrade for sure when available.<br>
<br>
<br>
[cut]<br>
<span class="gmail-">><br>
><br>
> Please feel free to share your comments and questions, I would very<br>
> appreciate to know your user expirience.<br>
<br>
</span>Sure, i'll do! And i'll bother you on irc if i need some guidance :-)<br>
<br>
Thank you so much,<br>
<br>
Luca<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
--<br>
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare<br>
calcoli che potrebbero essere affidati a chiunque se si usassero delle<br>
macchine"<br>
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)<br>
<br>
"Internet è la più grande biblioteca del mondo.<br>
Ma il problema è che i libri sono tutti sparsi sul pavimento"<br>
John Allen Paulos, Matematico (1945-vivente)<br>
<br>
Luca 'remix_tj' Lorenzetto, <a href="http://www.remixtj.net" rel="noreferrer" target="_blank">http://www.remixtj.net</a> , <<a href="mailto:lorenzetto.luca@gmail.com">lorenzetto.luca@gmail.com</a>><br>
</div></div></blockquote></div><br></div></div>