oVirt VM backup and restore
Dears Engineers, I hope you are doing great, I wish you can help me with a tutorial that shows how to take a scheduled backups for virtual machines running on oVirt node 4 and how to restore them. Best regards
This is a multi-part message in MIME format. --------------16A7F177EB0A59ABACA4F367 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hello, * With ovirt <=3D 4.1 and ovirtsdk3 : https://github.com/wefixit-AT/oVirtBackup This workflow works fine but will be soon deprecated. * With ovirt > 4.0, jhernandez has recently posted a new python script based on the new v4 API : https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm= _backup.py I personnally didn't try it, maybe someone could give a feedback. Le 29/01/2017 =E0 16:42, raphael awadallah a =E9crit :
Dears Engineers, I hope you are doing great, I wish you can help me with a tutorial that shows how to take a=20 scheduled backups for virtual machines running on oVirt node 4 and how=20 to restore them. Best regards
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--=20 Nathana=EBl Blanchet Supervision r=E9seau P=F4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=E9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------16A7F177EB0A59ABACA4F367 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <p>Hello,</p> <ul> <li>With ovirt <=3D 4.1 and ovirtsdk3 : <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/wef= ixit-AT/oVirtBackup">https://github.com/wefixit-AT/oVirtBackup</a></li> </ul> <p>This workflow works fine but will be soon deprecated.<br> </p> <ul> <li>With ovirt > 4.0, jhernandez has recently posted a new python script based on the new v4 API : <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/oVirt/ovirt= -engine-sdk/blob/master/sdk/examples/vm_backup.py">https://github.com/oVi= rt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py</a></li> </ul> <p>I personnally didn't try it, maybe someone could give a feedback.<= br> </p> <br> <div class=3D"moz-cite-prefix">Le 29/01/2017 =E0 16:42, raphael awadallah a =E9crit=A0:<br> </div> <blockquote cite=3D"mid:CAGGxq7AkyWx1tkV1KP=3DgpRPNvRdZOCYf6DNv8bF6EUdJDW-vNg@mail.gm= ail.com" type=3D"cite"> <div dir=3D"ltr"> <div> <div> <div>Dears Engineers,<br> </div> I hope you are doing great,<br> </div> I wish you can help me with a tutorial that shows how to take a scheduled backups for virtual machines running on oVirt node 4 and how to restore them.<br> </div> Best regards</div> <br> <fieldset class=3D"mimeAttachmentHeader"></fieldset> <br> <pre wrap=3D"">_______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org">Use= rs@ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman= /listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=EBl Blanchet Supervision r=E9seau P=F4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=E9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------16A7F177EB0A59ABACA4F367--
--_000_3077455AE9564D36B705CA0980B7028Eingramcontentcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 V2XigJlyZSBiZWVuIHVzaW5nIG9WaXJ0QmFja3VwIHdpdGggb3VyIG9WaXJ0IDQuMC41IGVudmly b25tZW50IGFuZCBpdOKAmXMgd29ya2VkIHdlbGwuIEl04oCZcyBub3QgdGhlIG1vc3QgZWZmaWNp ZW50ICggZmlyc3QgY3JlYXRlcyBhIHNuYXBzaG90LCB0aGVuIGNsb25lLCB0aGVuIGJhY2t1cCkg YnV0IHdlIGNhbiBsaXZlIHdpdGggaXQuDQoNCkhhcyBhbnlvbmUgdGVzdGVkIG9WaXJ0QmFja3Vw IHdpdGggb1ZpcnQgNC4xPyBEb2VzIGl0IHN0aWxsIHdvcms/IEkgd2FudCB0byBrbm93IGJlZm9y ZSB3ZSB1cGdyYWRlLiBJ4oCZZCBsaWtlIHRvIGV2ZW50dWFsbHkgdXNlIHRoZSBuZXcgdjQgQVBJ IGJ1dCBJIGhhdmVu4oCZdCBzZWVuIGEgbG90IG9mIGRvY3VtZW50YXRpb24gb24gaG93IGl0IHdv cmtzIGluIHByYWN0aWNlLg0KDQpUaGFua3MsDQpEYW5pZWwNCg0KRnJvbTogPHVzZXJzLWJvdW5j ZXNAb3ZpcnQub3JnPiBvbiBiZWhhbGYgb2YgTmF0aGFuYcOrbCBCbGFuY2hldCA8YmxhbmNoZXRA YWJlcy5mcj4NCkRhdGU6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxNyBhdCAzOjQ0IEFNDQpUbzog InVzZXJzQG92aXJ0Lm9yZyIgPHVzZXJzQG92aXJ0Lm9yZz4NClN1YmplY3Q6IFJlOiBbb3ZpcnQt dXNlcnNdIG9WaXJ0IFZNIGJhY2t1cCBhbmQgcmVzdG9yZQ0KDQoNCkhlbGxvLA0KDQogICogICBX aXRoIG92aXJ0IDw9IDQuMSBhbmQgb3ZpcnRzZGszIDogaHR0cHM6Ly9naXRodWIuY29tL3dlZml4 aXQtQVQvb1ZpcnRCYWNrdXANCg0KVGhpcyB3b3JrZmxvdyB3b3JrcyBmaW5lIGJ1dCB3aWxsIGJl IHNvb24gZGVwcmVjYXRlZC4NCg0KICAqICAgV2l0aCBvdmlydCA+IDQuMCwgamhlcm5hbmRleiBo YXMgcmVjZW50bHkgcG9zdGVkIGEgbmV3IHB5dGhvbiBzY3JpcHQgYmFzZWQgb24gdGhlIG5ldyB2 NCBBUEkgOiBodHRwczovL2dpdGh1Yi5jb20vb1ZpcnQvb3ZpcnQtZW5naW5lLXNkay9ibG9iL21h c3Rlci9zZGsvZXhhbXBsZXMvdm1fYmFja3VwLnB5DQoNCkkgcGVyc29ubmFsbHkgZGlkbid0IHRy eSBpdCwgbWF5YmUgc29tZW9uZSBjb3VsZCBnaXZlIGEgZmVlZGJhY2suDQoNCkxlIDI5LzAxLzIw MTcgw6AgMTY6NDIsIHJhcGhhZWwgYXdhZGFsbGFoIGEgw6ljcml0IDoNCkRlYXJzIEVuZ2luZWVy cywNCkkgaG9wZSB5b3UgYXJlIGRvaW5nIGdyZWF0LA0KSSB3aXNoIHlvdSBjYW4gaGVscCBtZSB3 aXRoIGEgdHV0b3JpYWwgdGhhdCBzaG93cyBob3cgdG8gdGFrZSBhIHNjaGVkdWxlZCBiYWNrdXBz IGZvciB2aXJ0dWFsIG1hY2hpbmVzIHJ1bm5pbmcgb24gb1ZpcnQgbm9kZSA0IGFuZCBob3cgdG8g cmVzdG9yZSB0aGVtLg0KQmVzdCByZWdhcmRzDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClVzZXJzIG1haWxpbmcgbGlzdA0KDQpVc2Vy c0BvdmlydC5vcmc8bWFpbHRvOlVzZXJzQG92aXJ0Lm9yZz4NCg0KaHR0cDovL2xpc3RzLm92aXJ0 Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQoNCg0KDQotLQ0KDQpOYXRoYW5hw6tsIEJsYW5j aGV0DQoNCg0KDQpTdXBlcnZpc2lvbiByw6lzZWF1DQoNClDDtGxlIEluZnJhc3RydXR1cmVzIElu Zm9ybWF0aXF1ZXMNCg0KMjI3IGF2ZW51ZSBQcm9mZXNzZXVyLUplYW4tTG91aXMtVmlhbGENCg0K MzQxOTMgTU9OVFBFTExJRVIgQ0VERVggNQ0KDQpUw6lsLiAzMyAoMCk0IDY3IDU0IDg0IDU1DQoN CkZheCAgMzMgKDApNCA2NyA1NCA4NCAxNA0KDQpibGFuY2hldEBhYmVzLmZyPG1haWx0bzpibGFu Y2hldEBhYmVzLmZyPg0K --_000_3077455AE9564D36B705CA0980B7028Eingramcontentcom_ Content-Type: text/html; charset=UTF-8 Content-ID: <5398D8108EC8A54788AA3AF2E4358545@namprd12.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo2OTgxMTI5NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTYzMDg2MzMyO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2OTIyMjA0MTc7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xMzk5OTY2MTcyO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglt c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5XZeKAmXJlIGJlZW4gdXNpbmcgb1ZpcnRCYWNrdXAgd2l0aCBvdXIgb1ZpcnQgNC4wLjUg ZW52aXJvbm1lbnQgYW5kIGl04oCZcyB3b3JrZWQgd2VsbC4gSXTigJlzIG5vdCB0aGUgbW9zdCBl ZmZpY2llbnQgKCBmaXJzdCBjcmVhdGVzIGEgc25hcHNob3QsIHRoZW4gY2xvbmUsIHRoZW4gYmFj a3VwKSBidXQgd2UgY2FuIGxpdmUgd2l0aA0KIGl0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5IYXMgYW55b25lIHRlc3RlZCBvVmlydEJhY2t1cCB3aXRoIG9WaXJ0IDQuMT8gRG9lcyBpdCBz dGlsbCB3b3JrPyBJIHdhbnQgdG8ga25vdyBiZWZvcmUgd2UgdXBncmFkZS4gSeKAmWQgbGlrZSB0 byBldmVudHVhbGx5IHVzZSB0aGUgbmV3IHY0IEFQSSBidXQgSSBoYXZlbuKAmXQgc2VlbiBhIGxv dCBvZiBkb2N1bWVudGF0aW9uIG9uDQogaG93IGl0IHdvcmtzIGluIHByYWN0aWNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj5EYW5pZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOmJsYWNrIj4mbHQ7dXNlcnMtYm91bmNlc0BvdmlydC5vcmcmZ3Q7IG9uIGJlaGFs ZiBvZiBOYXRoYW5hw6tsIEJsYW5jaGV0ICZsdDtibGFuY2hldEBhYmVzLmZyJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5Nb25kYXksIEphbnVhcnkgMzAsIDIwMTcgYXQgMzo0NCBBTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7dXNlcnNAb3ZpcnQub3JnJnF1b3Q7ICZsdDt1c2Vyc0BvdmlydC5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbb3ZpcnQtdXNlcnNdIG9WaXJ0IFZNIGJhY2t1cCBh bmQgcmVzdG9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5IZWxsbyw8bzpw PjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KV2l0aCBvdmlydCAmbHQ7PSA0LjEgYW5kIG92aXJ0c2Rr MyA6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS93ZWZpeGl0LUFUL29WaXJ0QmFja3VwIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS93ZWZpeGl0LUFUL29WaXJ0QmFja3VwPC9hPiA8bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwPlRoaXMgd29ya2Zsb3cgd29ya3MgZmluZSBidXQgd2lsbCBiZSBzb29u IGRlcHJlY2F0ZWQuPG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCldpdGggb3ZpcnQgJmd0OyA0 LjAsIGpoZXJuYW5kZXogaGFzIHJlY2VudGx5IHBvc3RlZCBhIG5ldyBweXRob24gc2NyaXB0IGJh c2VkIG9uIHRoZSBuZXcgdjQgQVBJIDoNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vVmly dC9vdmlydC1lbmdpbmUtc2RrL2Jsb2IvbWFzdGVyL3Nkay9leGFtcGxlcy92bV9iYWNrdXAucHki Pg0KaHR0cHM6Ly9naXRodWIuY29tL29WaXJ0L292aXJ0LWVuZ2luZS1zZGsvYmxvYi9tYXN0ZXIv c2RrL2V4YW1wbGVzL3ZtX2JhY2t1cC5weTwvYT4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHA+ SSBwZXJzb25uYWxseSBkaWRuJ3QgdHJ5IGl0LCBtYXliZSBzb21lb25lIGNvdWxkIGdpdmUgYSBm ZWVkYmFjay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDI5LzAxLzIwMTcgw6Ag MTY6NDIsIHJhcGhhZWwgYXdhZGFsbGFoIGEgw6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFycyBFbmdpbmVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaG9wZSB5b3UgYXJlIGRvaW5nIGdyZWF0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpc2ggeW91IGNhbiBoZWxwIG1lIHdpdGggYSB0dXRv cmlhbCB0aGF0IHNob3dzIGhvdyB0byB0YWtlIGEgc2NoZWR1bGVkIGJhY2t1cHMgZm9yIHZpcnR1 YWwgbWFjaGluZXMgcnVubmluZyBvbiBvVmlydCBub2RlIDQgYW5kIGhvdyB0byByZXN0b3JlIHRo ZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVn YXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Vc2VycyBtYWls aW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86VXNlcnNAb3Zp cnQub3JnIj5Vc2Vyc0BvdmlydC5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl Zj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIj5odHRwOi8v bGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8L2E+PG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5OYXRoYW5hw6tsIEJs YW5jaGV0PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+U3VwZXJ2aXNpb24gcsOpc2VhdTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlDDtGxlIEluZnJh c3RydXR1cmVzIEluZm9ybWF0aXF1ZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yMjcgYXZlbnVl IFByb2Zlc3NldXItSmVhbi1Mb3Vpcy1WaWFsYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjM0MTkz IE1PTlRQRUxMSUVSIENFREVYIDUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPlTDqWwuIDMzICgwKTQgNjcgNTQgODQgNTU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5GYXgmbmJzcDsgMzMgKDApNCA2NyA1NCA4NCAxNDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzpibGFuY2hldEBhYmVzLmZyIj5ibGFuY2hldEBhYmVzLmZyPC9hPiA8 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3077455AE9564D36B705CA0980B7028Eingramcontentcom_--
On Tue, Feb 7, 2017 at 6:05 PM, Beckman, Daniel < Daniel.Beckman@ingramcontent.com> wrote:
We’re been using oVirtBackup with our oVirt 4.0.5 environment and it’s worked well. It’s not the most efficient ( first creates a snapshot, then clone, then backup) but we can live with it.
Has anyone tested oVirtBackup with oVirt 4.1? Does it still work? I want to know before we upgrade. I’d like to eventually use the new v4 API but I haven’t seen a lot of documentation on how it works in practice.
Thanks,
Daniel
*From: *<users-bounces@ovirt.org> on behalf of Nathanaël Blanchet < blanchet@abes.fr> *Date: *Monday, January 30, 2017 at 3:44 AM *To: *"users@ovirt.org" <users@ovirt.org> *Subject: *Re: [ovirt-users] oVirt VM backup and restore
Hello,
- With ovirt <= 4.1 and ovirtsdk3 : https://github.com/wefixit-AT/ oVirtBackup
This workflow works fine but will be soon deprecated.
- With ovirt > 4.0, jhernandez has recently posted a new python script based on the new v4 API : https://github.com/oVirt/ ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py <https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py>
I personnally didn't try it, maybe someone could give a feedback.
I'm running some tests in a 4.1 testenvironment. At the moment testing on a Oracle Linux 7.3 VM - using oVirtBackup from master (version is on 3rd of July 2016) $ ./backup.py -c config_test.cfg Mar 08 17:37:08: Start backup for: Oracle7 Mar 08 17:37:09: Snapshot creation started ... Mar 08 17:38:23: Snapshot created Mar 08 17:38:33: Clone into VM started ... Mar 08 17:40:31: Cloning finished Mar 08 17:40:32: Snapshot deletion started ... Mar 08 17:41:53: Snapshots deleted Mar 08 17:41:54: Export started ... Mar 08 17:43:56: Exporting finished Mar 08 17:43:57: Delete cloned VM started ... Mar 08 17:44:01: Cloned VM deleted Mar 08 17:44:01: Duration: 6:54 minutes Mar 08 17:44:01: VM exported as Oracle7_BACKUP_20170308_173708 Mar 08 17:44:01: Backup done for: Oracle7 Mar 08 17:44:01: All backups done NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages: Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started Is this expected? Not yet used the vm_backup.py, I;m trying to get sdk4 on Fedora 25 before (see the other thread I opened)... Gianluca
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM In the mean time I verified changing backup.py this way solves the problem (the 3.6 api deprecation still in place... ;-): $ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=False)) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm)) The snapshot doesn't include memory and no problem at VM OS side now Tested also getting the parameter from config file Modifications needed in this case: 1) $ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=config.get_persist_memorystate())) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm)) 2) $ diff config.py config.py.orig 34d33 < self.__persist_memorystate = config_parser.getboolean(section, "persist_memorystate") 113,116d111 < < < def get_persist_memorystate(self): < return self.__persist_memorystate And in config file called add: # Save Memory in snapshot persist_memorystate=False It could be further improved if one wants to differentiate save memory for some VMs and not for other ones.... HIH other ones, Gianluca
On 03/09/2017 10:25 AM, Gianluca Cecchi wrote:
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
In the mean time I verified changing backup.py this way solves the problem (the 3.6 api deprecation still in place... ;-):
$ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=False)) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm))
The snapshot doesn't include memory and no problem at VM OS side now
Tested also getting the parameter from config file
Modifications needed in this case:
1) $ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=config.get_persist_memorystate())) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm))
2) $ diff config.py config.py.orig 34d33 < self.__persist_memorystate = config_parser.getboolean(section, "persist_memorystate") 113,116d111 < < < def get_persist_memorystate(self): < return self.__persist_memorystate
And in config file called add:
# Save Memory in snapshot persist_memorystate=False
It could be further improved if one wants to differentiate save memory for some VMs and not for other ones....
HIH other ones, Gianluca
Very good point Gialuca, you are right, the 'persist_memorystate' flag is 'true' by default, and that makes the pause longer. Would you be so kind to add it to the 'vm_backup.py' example that is part of version 4 of the SDK? https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup... (Note that that Gibhub is just a mirror, the change needs to be submited using gerrit.ovirt.org).
On Thu, Mar 9, 2017 at 10:58 AM, Juan Hernández <jhernand@redhat.com> wrote:
Very good point Gialuca, you are right, the 'persist_memorystate' flag is 'true' by default, and that makes the pause longer. Would you be so kind to add it to the 'vm_backup.py' example that is part of version 4 of the SDK?
https://github.com/oVirt/ovirt-engine-sdk/blob/master/ sdk/examples/vm_backup.py#L143-L151
(Note that that Gibhub is just a mirror, the change needs to be submited using gerrit.ovirt.org).
I already verified (on a 4.1 infra) that changing vm_backup.py downloaded yesterday from master this way (apart connection paramters): $ diff vm_backup.py vm_backup.py.orig 150d149 < persist_memorystate=False, I get the backup result and snapshot is correctly without memory saved (and no pause at VM side) In engine events I get: Mar 9, 2017 10:50:39 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' deletion for VM 'Oracle7' has been completed. Mar 9, 2017 10:49:48 AM Backup of virtual machine 'Oracle7' using snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' is completed. Mar 9, 2017 10:49:48 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' deletion for VM 'Oracle7' was initiated by admin@internal-authz. Mar 9, 2017 10:49:47 AM Disk Oracle7_Disk1 was successfully detached from VM c7testovn1 by admin@internal-authz. Mar 9, 2017 10:49:45 AM Disk Oracle7_Disk1 was successfully attached to VM c7testovn1 by admin@internal-authz. Mar 9, 2017 10:49:41 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' creation for VM 'Oracle7' has been completed. Mar 9, 2017 10:49:29 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' creation for VM 'Oracle7' was initiated by admin@internal-authz. Mar 9, 2017 10:49:28 AM Backup of virtual machine 'Oracle7' using snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' is starting. I have almost no experience in gerrit/github, unfortunately... only a beginner experience in svn ... ;-) If you give me some pointers I can try to apply what you asked... Gianluca
On 03/09/2017 11:11 AM, Gianluca Cecchi wrote:
On Thu, Mar 9, 2017 at 10:58 AM, Juan Hernández <jhernand@redhat.com <mailto:jhernand@redhat.com>> wrote:
Very good point Gialuca, you are right, the 'persist_memorystate' flag is 'true' by default, and that makes the pause longer. Would you be so kind to add it to the 'vm_backup.py' example that is part of version 4 of the SDK?
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup... <https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py#L143-L151>
(Note that that Gibhub is just a mirror, the change needs to be submited using gerrit.ovirt.org <http://gerrit.ovirt.org>).
I already verified (on a 4.1 infra) that changing vm_backup.py downloaded yesterday from master this way (apart connection paramters):
$ diff vm_backup.py vm_backup.py.orig 150d149 < persist_memorystate=False,
I get the backup result and snapshot is correctly without memory saved (and no pause at VM side)
In engine events I get:
Mar 9, 2017 10:50:39 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' deletion for VM 'Oracle7' has been completed. Mar 9, 2017 10:49:48 AM Backup of virtual machine 'Oracle7' using snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' is completed. Mar 9, 2017 10:49:48 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' deletion for VM 'Oracle7' was initiated by admin@internal-authz. Mar 9, 2017 10:49:47 AM Disk Oracle7_Disk1 was successfully detached from VM c7testovn1 by admin@internal-authz. Mar 9, 2017 10:49:45 AM Disk Oracle7_Disk1 was successfully attached to VM c7testovn1 by admin@internal-authz. Mar 9, 2017 10:49:41 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' creation for VM 'Oracle7' has been completed. Mar 9, 2017 10:49:29 AM Snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' creation for VM 'Oracle7' was initiated by admin@internal-authz. Mar 9, 2017 10:49:28 AM Backup of virtual machine 'Oracle7' using snapshot 'Oracle7-backup-c6bf637e-cdeb-4923-a39f-55a14d7bad7b' is starting.
I have almost no experience in gerrit/github, unfortunately... only a beginner experience in svn ... ;-) If you give me some pointers I can try to apply what you asked...
Gianluca
I see that you already have a gerrit.ovirt.org, so it shouldn't be difficult. The initial setup should be like this: $ git config --global user.name youruser $ git config --global user.email your@email $ git clone ssh://youruser@gerrit.ovirt.org:29418/ovirt-engine-sdk $ gitdir=$(git rev-parse --git-dir); scp -p -P 29418 youruser@gerrit.ovirt.org:hooks/commit-msg ${gitdir}/hooks/ Then, to submit the patch: $ cd ovirt-engine-sdk $ Edit the vm_backup.py file, and make your changes. $ git commit -a -s $ git push origin HEAD:refs/for/master
On Thu, Mar 9, 2017 at 11:23 AM, Juan Hernández <jhernand@redhat.com> wrote:
Very good point Gialuca, you are right, the 'persist_memorystate'
flag
is 'true' by default, and that makes the pause longer. Would you be
so
kind to add it to the 'vm_backup.py' example that is part of version
4
of the SDK?
sdk/examples/vm_backup.py#L143-L151
sdk/examples/vm_backup.py#L143-L151>
(Note that that Gibhub is just a mirror, the change needs to be
submited
using gerrit.ovirt.org <http://gerrit.ovirt.org>).
I already verified (on a 4.1 infra) that changing vm_backup.py downloaded yesterday from master this way (apart connection paramters):
$ diff vm_backup.py vm_backup.py.orig 150d149 < persist_memorystate=False,
I get the backup result and snapshot is correctly without memory saved (and no pause at VM side)
[snip]
I see that you already have a gerrit.ovirt.org, so it shouldn't be difficult. The initial setup should be like this:
$ git config --global user.name youruser $ git config --global user.email your@email $ git clone ssh://youruser@gerrit.ovirt.org:29418/ovirt-engine-sdk $ gitdir=$(git rev-parse --git-dir); scp -p -P 29418 youruser@gerrit.ovirt.org:hooks/commit-msg ${gitdir}/hooks/
Then, to submit the patch:
$ cd ovirt-engine-sdk $ Edit the vm_backup.py file, and make your changes. $ git commit -a -s $ git push origin HEAD:refs/for/master
Ok. I found the time to try and apparently it worked as expected. The master (you? jenkins CI? ;-) should see my change... Just learnt (a little...) another thing sys admins often try to put an eye inside devs field but the reverse seldom happens ;-)
This is a multi-part message in MIME format. --------------DF760123B34BA11C0A26BA44 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 09/03/2017 =C3=A0 10:25, Gianluca Cecchi a =C3=A9crit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi=20 <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it=20 saves memory and so this implies pause of VM Saving memory is essential in some ap=C3=A0plications like DB, so you won= 't=20 bypass vm pauses for such a stuff In the mean time I verified changing backup.py this way solves the=20 problem (the 3.6 api deprecation still in place... ;-):
$ diff backup.py backup.py.orig 123c123 <=20 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_desc= ription(),=20 vm=3Dvm,persist_memorystate=3DFalse)) ---
=20 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_desc= ription(),=20 vm=3Dvm))
The snapshot doesn't include memory and no problem at VM OS side now
Tested also getting the parameter from config file
Modifications needed in this case:
1) $ diff backup.py backup.py.orig 123c123 <=20 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_desc= ription(),=20 vm=3Dvm,persist_memorystate=3Dconfig.get_persist_memorystate())) ---
=20 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_desc= ription(),=20 vm=3Dvm))
2) $ diff config.py config.py.orig 34d33 < self.__persist_memorystate =3D=20 config_parser.getboolean(section, "persist_memorystate") 113,116d111 < < < def get_persist_memorystate(self): < return self.__persist_memorystate
And in config file called add:
# Save Memory in snapshot persist_memorystate=3DFalse
It could be further improved if one wants to differentiate save memory=20 for some VMs and not for other ones....
HIH other ones, Gianluca
--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------DF760123B34BA11C0A26BA44 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <p><br> </p> <br> <div class=3D"moz-cite-prefix">Le 09/03/2017 =C3=A0 10:25, Gianluca C= ecchi a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:CAG2kNCy-F6KF0ckEbFqWuXYQkroMZRVigPHvuhsrK=3DEvBBOTpQ@mail.gm= ail.com" type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote">On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <span dir=3D"ltr"><<a moz-do-not-send=3D"true" href=3D"mailto:gianluca.cecchi@gmail.com" target=3D"_blan= k">gianluca.cecchi@gmail.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"><br> <div><br> </div> <div>NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session.</div> <div>After a couple of seconds it comes back and as a confirmation I see this in its messages:</div> <div><br> </div> <div>Mar =C2=A08 17:38:57 T-ORACLE73 chronyd[616]: Sy= stem clock wrong by 19.077230 seconds, adjustment started<br> </div> <div><br> </div> <div>Is this expected?</div> <div><br> </div> <span class=3D"gmail-HOEnZb"><font color=3D"#888888"> <div><br> </div> <div><br> </div> </font></span></div> </div> </div> </blockquote> </div> <br> </div> <div class=3D"gmail_extra">Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM</div> </div> </blockquote> Saving memory is essential in some ap=C3=A0plications like DB, so you won't bypass vm pauses for such a stuff<br> <blockquote cite=3D"mid:CAG2kNCy-F6KF0ckEbFqWuXYQkroMZRVigPHvuhsrK=3DEvBBOTpQ@mail.gm= ail.com" type=3D"cite"> <div dir=3D"ltr"> <div class=3D"gmail_extra">In the mean time I verified changing backup.py this way solves the problem (the 3.6 api deprecation still in place... ;-):</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra"> <div class=3D"gmail_extra">$ diff backup.py backup.py.orig=C2=A0= </div> <div class=3D"gmail_extra">123c123</div> <div class=3D"gmail_extra">< =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_descri= ption(), vm=3Dvm,persist_memorystate=3DFalse))</div> <div class=3D"gmail_extra">---</div> <div class=3D"gmail_extra">> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_descri= ption(), vm=3Dvm))</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">The snapshot doesn't include memory and no problem at VM OS side now</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">Tested also getting the parameter from config file</div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">Modifications needed in this case:</= div> <div class=3D"gmail_extra"><br> </div> <div class=3D"gmail_extra">1)</div> <div class=3D"gmail_extra">$ diff backup.py backup.py.orig=C2=A0= <br> </div> <div class=3D"gmail_extra"> <div class=3D"gmail_extra">123c123</div> <div class=3D"gmail_extra">< =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_descri= ption(), vm=3Dvm,persist_memorystate=3Dconfig.get_persist_memorystate()))</div> <div class=3D"gmail_extra">---</div> <div class=3D"gmail_extra">> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vm.snapshots.add(params.Snapshot(description=3Dconfig.get_snapshot_descri= ption(), vm=3Dvm))</div> <div><br> </div> <div><br> </div> <div>2)</div> <div> <div>$ diff config.py config.py.orig=C2=A0</div> <div>34d33</div> <div>< =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.__= persist_memorystate =3D config_parser.getboolean(section, "persist_memorystate")<= /div> <div>113,116d111</div> <div><=C2=A0</div> <div><=C2=A0</div> <div>< =C2=A0 =C2=A0 def get_persist_memorystate(self):<= /div> <div>< =C2=A0 =C2=A0 =C2=A0 =C2=A0 return self.__persist= _memorystate</div> </div> <div><br> </div> <div><br> </div> <div>And in config file called add:</div> <div><br> </div> </div> <div> <div># Save Memory in snapshot</div> <div>persist_memorystate=3DFalse</div> </div> <div><br> </div> <div>It could be further improved if one wants to differentiate save memory for some VMs and not for other ones....</div> <div><br> </div> <div>HIH other ones,</div> <div>Gianluca</div> </div> </div> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------DF760123B34BA11C0A26BA44--
On Thu, Mar 9, 2017 at 12:40 PM Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com
wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
In a database, you actually want to ensure all transactions are complete for an application-complete snapshot. I don't think memory is needed. Y.
In the mean time I verified changing backup.py this way solves the problem (the 3.6 api deprecation still in place... ;-):
$ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=False)) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm))
The snapshot doesn't include memory and no problem at VM OS side now
Tested also getting the parameter from config file
Modifications needed in this case:
1) $ diff backup.py backup.py.orig 123c123 < vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm,persist_memorystate=config.get_persist_memorystate())) ---
vm.snapshots.add(params.Snapshot(description=config.get_snapshot_description(), vm=vm))
2) $ diff config.py config.py.orig 34d33 < self.__persist_memorystate = config_parser.getboolean(section, "persist_memorystate") 113,116d111 < < < def get_persist_memorystate(self): < return self.__persist_memorystate
And in config file called add:
# Save Memory in snapshot persist_memorystate=False
It could be further improved if one wants to differentiate save memory for some VMs and not for other ones....
HIH other ones, Gianluca
-- Nathanaël Blanchet
Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14blanchet@abes.fr
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com
wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous-archiving.html#BACKUP-... and the same for other ones. Gianluca
My 2cents I think it would be very handy to be able to choose to save the memory state or not. As for anything requiring the memory state depends very much on what your recovery procedure is. Gianluca, PostgreSQL pg_start / end backup works very well. I can't remember exactly how it works but it's something along the lines of stopping (disk) writes to the database and storing change in WAL (redo in oracle speak) until the backup is complete then applying any changes to the database files on disk. Basically means that the database files won't change during the backup process. On 9 March 2017 at 10:57, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi < gianluca.cecchi@gmail.com> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous- archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP and the same for other ones.
Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 03/09/2017 11:57 AM, Gianluca Cecchi wrote:
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous-archiving.html#BACKUP-... and the same for other ones.
Gianluca
Just wanted to add that freezing activity is not only important for databases, but also for plain file systems. In order to do a consistent backup it is important to freeze the file systems before creating a live snapshot, and thaw it afterwards. oVirt does that automatically, but only if the guest agent is installed and running. So, remember to have the guest agent installed and running in the virtual machines that you plan to backup using this mechanism.
Good point On 9 March 2017 at 11:10, Juan Hernández <jhernand@redhat.com> wrote:
On 03/09/2017 11:57 AM, Gianluca Cecchi wrote:
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>>
wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous- archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP and the same for other ones.
Gianluca
Just wanted to add that freezing activity is not only important for databases, but also for plain file systems. In order to do a consistent backup it is important to freeze the file systems before creating a live snapshot, and thaw it afterwards. oVirt does that automatically, but only if the guest agent is installed and running. So, remember to have the guest agent installed and running in the virtual machines that you plan to backup using this mechanism.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Thu, Mar 9, 2017 at 12:11 PM, Maton, Brett <matonb@ltresources.co.uk> wrote:
Good point
Just wanted to add that freezing activity is not only important for databases, but also for plain file systems. In order to do a consistent backup it is important to freeze the file systems before creating a live snapshot, and thaw it afterwards. oVirt does that automatically, but only if the guest agent is installed and running. So, remember to have the guest agent installed and running in the virtual machines that you plan to backup using this mechanism.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Yes, indeed. I forgot to write it before, but I did verify that my VM with guest agent installed had this inside its /var/log/messages file: Mar 9 10:49:36 T-ORACLE73 qemu-ga: info: guest-fsfreeze called Mar 9 10:49:36 T-ORACLE73 qemu-ga: info: executing fsfreeze hook with arg 'freeze' Mar 9 10:49:37 T-ORACLE73 qemu-ga: info: executing fsfreeze hook with arg 'thaw' Also, with vm_backup.py utility, I verified that inside the VM where the snapshotted disk was attached (c7testovn1), I got this: Mar 9 10:49:42 c7testovn1 kernel: pci 0000:00:09.0: BAR 4: assigned [mem 0x40000000-0x40003fff 64bit pref] Mar 9 10:49:42 c7testovn1 kernel: pci 0000:00:09.0: BAR 1: assigned [mem 0x40004000-0x40004fff] Mar 9 10:49:42 c7testovn1 kernel: pci 0000:00:09.0: BAR 0: assigned [io 0x1000-0x103f] Mar 9 10:49:42 c7testovn1 kernel: virtio-pci 0000:00:09.0: enabling device (0000 -> 0003) Mar 9 10:49:42 c7testovn1 kernel: vdb: vdb1 vdb2 Mar 9 10:49:42 c7testovn1 systemd: Starting LVM2 PV scan on device 252:18... Mar 9 10:49:42 c7testovn1 lvm: 2 logical volume(s) in volume group "mainvg" now active Mar 9 10:49:42 c7testovn1 systemd: Started LVM2 PV scan on device 252:18. Mar 9 10:49:44 c7testovn1 systemd: Stopping LVM2 PV scan on device 252:18... Mar 9 10:49:44 c7testovn1 lvm: Device 252:18 not found. Cleared from lvmetad cache. Mar 9 10:49:44 c7testovn1 systemd: Stopped LVM2 PV scan on device 252:18. Gianluca
Le 09/03/2017 à 12:10, Juan Hernández a écrit :
On 03/09/2017 11:57 AM, Gianluca Cecchi wrote:
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous-archiving.html#BACKUP-... and the same for other ones.
Gianluca
Just wanted to add that freezing activity is not only important for databases, but also for plain file systems. In order to do a consistent backup it is important to freeze the file systems before creating a live snapshot, and thaw it afterwards. oVirt does that automatically, but only if the guest agent is installed and running. So, remember to have the guest agent installed and running in the virtual machines that you plan to backup using this mechanism. Very useful piece of information, so does that mean memory save feature not to be really useful? if so, it shouldn't be the default, so that vm never go into pause state unusefully.
-- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr
On 03/09/2017 02:10 PM, Nathanaël Blanchet wrote:
Le 09/03/2017 à 12:10, Juan Hernández a écrit :
On 03/09/2017 11:57 AM, Gianluca Cecchi wrote:
On Thu, Mar 9, 2017 at 11:39 AM, Nathanaël Blanchet <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote:
Le 09/03/2017 à 10:25, Gianluca Cecchi a écrit :
On Wed, Mar 8, 2017 at 6:05 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com <mailto:gianluca.cecchi@gmail.com>> wrote:
NOTE: during the snapshot creation I see in web admin console the VM in paused state and also not responsive in both console and ssh session. After a couple of seconds it comes back and as a confirmation I see this in its messages:
Mar 8 17:38:57 T-ORACLE73 chronyd[616]: System clock wrong by 19.077230 seconds, adjustment started
Is this expected?
Possibly the default changed at some point in time, so that now it saves memory and so this implies pause of VM
Saving memory is essential in some apàplications like DB, so you won't bypass vm pauses for such a stuff
Yes, indeed, the important thing is to have an option so that you can set it True or False, depending on the VM you are saving, the application that is running isnide it and the way you want to do backup of the application. Nevertheless, RDBMS and also other applications often have some mechanism to be "frozen in a consistent state" so that you can save what you have on disk without need to save memory to have a consistent backup. Oracle for example has functionality to be put in "backup mode" where you issue "begin backup" before the snapshot and "end backup" right after snapshot completion. I see that POstgreSQL has similar functionality (not tested myself): https://www.postgresql.org/docs/9.4/static/continuous-archiving.html#BACKUP-...
and the same for other ones.
Gianluca
Just wanted to add that freezing activity is not only important for databases, but also for plain file systems. In order to do a consistent backup it is important to freeze the file systems before creating a live snapshot, and thaw it afterwards. oVirt does that automatically, but only if the guest agent is installed and running. So, remember to have the guest agent installed and running in the virtual machines that you plan to backup using this mechanism. Very useful piece of information, so does that mean memory save feature not to be really useful? if so, it shouldn't be the default, so that vm never go into pause state unusefully.
I didn't mean that saving memory isn't useful. It is very useful, for certain use cases. For the backup use case I think it is better to disable it.
On Sun, Jan 29, 2017 at 5:42 PM, raphael awadallah <raphael.awadallah@gmail.com> wrote:
Dears Engineers, I hope you are doing great, I wish you can help me with a tutorial that shows how to take a scheduled backups for virtual machines running on oVirt node 4 and how to restore them.
From oVirt's project point of view, we only supply an API for this, no actual end-user tools. See also:
https://www.ovirt.org/develop/release-management/features/storage/backup-res... If you search the net for e.g. 'ovirt backup vms', you can find lots of stuff - actual tools, blog posts, mailing lists/forum discussions, etc. Many of these were also mentioned/discussed on this list over the years, so you can search also the list archives. Personally I do not have experience with any of the tools, so can't comment. If you need help with something specific you are trying to do - such as use one of the existing tools, or use the api directly, etc. - then please provide more details about what you are trying to do and what problems you run into. Best, -- Didi
participants (8)
-
Beckman, Daniel -
Gianluca Cecchi -
Juan Hernández -
Maton, Brett -
Nathanaël Blanchet -
raphael awadallah -
Yaniv Kaul -
Yedidyah Bar David