- Users - oVirt List Archives

Migration from oVirt to RHEV
by FERNANDO FREDIANI 29 Mar '17

29 Mar '17

Hi there. I currently have a oVirt environment and we are disposed to support the development of the project so decided to purchase the Subscriptions for RHEV. In order to do a smooth migration what is the best way ? Can I add a RHEV Node to oVirt Engine and live migrate Virtual Machines then disconnect the RHEV Node and connect it to RHEV engine ? Or the contrary, bring up a RHEV Engine up, disconnect oVirt-Nodes and connect them to the RHEV Engine, than migrate the Virtual Machines to RHEV Host. In the case none of the above is possible how can I migrate my oVirt running VMs to RHEV enviroment without much hassle ? Thanks Fernando

3 2

oVirt 3.6 on CentOS 7.1 based HyperConverged DC : Upgradable?
by Nicolas Ecarnot 29 Mar '17

29 Mar '17

Hello, One of our DC is a very small one, though quite critical. It's almost hyper converged : hosts are compute+storage, but the engine is standalone. It's made of : Hardware : - one physical engine : CentOS 7.1 - 3 physical hosts : CentOS 7.2 Software : - oVirt 3.6.5 - glusterFS 3.7.16 in replica-3, sharded. The goal is to upgrade all this to oVirt 4.1.1, and if possible also upgrade the OSes. At present, only 3 VMs here are critical, and I have backups for them. Though, I'm quite nervous with the path I have to follow and the hazards. Especially about the gluster parts. At first glance, I would go this way (feel free to comment) : - upgrade the OS of the engine : 7.1 -> 7.3 - upgrade the OS of the hosts : 7.2 -> 7.3 - upgrade and manage the upgrade of gluster, check the volumes... - upgrade oVirt (engine then hosts) But when upgrading the OSes, I guess it will also upgrade the gluster layer. During this upgrade, I have no constraint to keep everything running, total shutdown is acceptable. Is the above procedure seems OK, or may am I missing some essential points? Thank you. -- Nicolas ECARNOT

1 0

Import KVM/libvirt VMs to oVirt 4.1 with External Provider
by Pradeep Antil 29 Mar '17

29 Mar '17

Hello Folks, I am trying to import KVM guest VMs to my oVirt Server using external Provider. But when i add external provider with type KVM and do the testing that time i am getting below error Caused by: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsNamesFromExternalProviderVDS, error = Cannot recv data: Host key verification failed.: Connection reset by peer, code = 65 at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createDefaultConcreteException(VdsBrokerCommand.java:76) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.createException(BrokerCommandBase.java:222) [vdsbroker.jar:] [image: Inline image 2] I have already configure password less authentication with ssh keys between proxy host to my KVM hypervisor. Though i can reach to kvm hypervisor with virsh connect. [root@lplinnd1hypov13 ~]# virsh -c qemu+ssh://root@<KVM-HYP-NAME>/system Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # Any idea how to resolve this issue, so that i can add KVM as external provider and start importing my KVM guest VMs in ovirt setup Thanks in Advance -- Best Regards Pradeep Kumar

2 1

VM "hot" RAM memory decrease
by Nicolás 29 Mar '17

29 Mar '17

Hi, I don't really know if this question is suitable on this list, as I doubt it's an oVirt bug, neither I know if it shall be considered a bug. We recently run a VM on a host that was memory over-used (around 80% of usage). The VM booted correctly, then we run "top" and saw how physical RAM started decreasing every two seconds. At first it was 4GB, then less and less until it stabilized at around 600MB. Based on this (correct me if I'm wrong), we believe this is an effect of having this VM with ballooning enabled, as it does exactly this: It adds/removes RAM depending on host decision. Thing is that this VM had a minimal guaranteed RAM of 1GB, so even if this happened due to ballooning, I'm not sure if it should have honored the minimum guaranteed RAM. When this happened, we run a 'ps' to see with what options the qemu process was invoked, and parameters seemed correct (that's why I don't know if it should be posted here or even if it's a bug). Is this the expected behavior? Thanks.

4 6

Memory treshold
by vasily.lamykin 29 Mar '17

29 Mar '17

--_004_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_ Content-Type: multipart/alternative; boundary="_000_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_" --_000_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLg0KRXhwbGFpbiBwbGVhc2UsIHdoZXJlIEkgY2FuIGRpc2FibGUgZm9yIGNsdXN0ZXIg dGhpcyB0aHJlc2hvbGQ6DQpVc2VkIG1lbW9yeSBvZiBob3N0ICoqKiBbOTglXSBleGNlZWRlZCBk ZWZpbmVkIHRocmVzaG9sZCBbOTUlXS4NCj8NCg0K0JLQsNGB0LjQu9C40Lkg0JvQsNC80YvQutC4 0L0NCtCh0YLQsNGA0YjQuNC5INC40L3QttC10L3QtdGAINC/0L4g0Y3QutGB0L/Qu9GD0LDRgtCw 0YbQuNC4INGB0LXRgNCy0LjRgdC90YvRhSDQv9C70LDRgtGE0L7RgNC8DQrQrdC60YHQv9C70YPQ sNGC0LDRhtC40Y8g0YHQtdGC0LgNCtCh0YLQvtC70LjRh9C90YvQuSDRhNC40LvQuNCw0Lsg0J/Q kNCeIMKr0JzQtdCz0LDQpNC+0L3Cuw0KKzcgKDkyNikgNTAwLTMzMDgNClvQnNC10LPQsNCk0L7Q vSDQu9C+0LPQvivQt9C90LDQuiDQoNCj0KEgQjJDXQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCtCY0L3RhNC+0YDQvNCw0YbQuNGPINCyINGN0YLQvtC8INGB0L7QvtCx 0YnQtdC90LjQuCDQv9GA0LXQtNC90LDQt9C90LDRh9C10L3QsCDQuNGB0LrQu9GO0YfQuNGC0LXQ u9GM0L3QviDQtNC70Y8g0LrQvtC90LrRgNC10YLQvdGL0YUg0LvQuNGGLCDQutC+0YLQvtGA0YvQ vCDQvtC90LAg0LDQtNGA0LXRgdC+0LLQsNC90LAuINCSINGB0L7QvtCx0YnQtdC90LjQuCDQvNC+ 0LbQtdGCINGB0L7QtNC10YDQttCw0YLRjNGB0Y8g0LrQvtC90YTQuNC00LXQvdGG0LjQsNC70YzQ vdCw0Y8g0LjQvdGE0L7RgNC80LDRhtC40Y8sINC60L7RgtC+0YDQsNGPINC90LUg0LzQvtC20LXR giDQsdGL0YLRjCDRgNCw0YHQutGA0YvRgtCwINC40LvQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC9 0LAg0LrQtdC8LdC70LjQsdC+LCDQutGA0L7QvNC1INCw0LTRgNC10YHQsNGC0L7Qsi4g0JXRgdC7 0Lgg0LLRiyDQvdC1INCw0LTRgNC10YHQsNGCINGN0YLQvtCz0L4g0YHQvtC+0LHRidC10L3QuNGP LCDRgtC+INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC1LCDQv9C10YDQtdCw0LTRgNC10YHQsNGG 0LjRjywg0LrQvtC/0LjRgNC+0LLQsNC90LjQtSDQuNC70Lgg0YDQsNGB0L/RgNC+0YHRgtGA0LDQ vdC10L3QuNC1INGB0L7QtNC10YDQttCw0L3QuNGPINGB0L7QvtCx0YnQtdC90LjRjyDQuNC70Lgg 0LXQs9C+INGH0LDRgdGC0Lgg0L3QtdC30LDQutC+0L3QvdC+INC4INC30LDQv9GA0LXRidC10L3Q vi4g0JXRgdC70Lgg0JLRiyDQv9C+0LvRg9GH0LjQu9C4INGN0YLQviDRgdC+0L7QsdGJ0LXQvdC4 0LUg0L7RiNC40LHQvtGH0L3Qviwg0L/QvtC20LDQu9GD0LnRgdGC0LAsINC90LXQt9Cw0LzQtdC0 0LvQuNGC0LXQu9GM0L3QviDRgdC+0L7QsdGJ0LjRgtC1INC+0YLQv9GA0LDQstC40YLQtdC70Y4g 0L7QsSDRjdGC0L7QvCDQuCDRg9C00LDQu9C40YLQtSDRgdC+INCy0YHQtdC8INGB0L7QtNC10YDQ ttC40LzRi9C8INGB0LDQvNC+INGB0L7QvtCx0YnQtdC90LjQtSDQuCDQu9GO0LHRi9C1INCy0L7Q t9C80L7QttC90YvQtSDQtdCz0L4g0LrQvtC/0LjQuCDQuCDQv9GA0LjQu9C+0LbQtdC90LjRjy4N Cg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGNvbW11bmljYXRpb24gaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIGl0IGlzIGFkZHJlc3NlZCBhbmQgb3RoZXJzIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBpdC4g SXQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIGxlZ2FsbHkgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbi4gVGhlIGNvbnRlbnRzIG1heSBub3QgYmUgZGlzY2xvc2VkIG9yIHVzZWQgYnkgYW55b25l IG90aGVyIHRoYW4gdGhlIGFkZHJlc3NlZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKSwgYW55IHVzZSwgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9y IGFueSBhY3Rpb24gdGFrZW4gb3Igb21pdHRlZCB0byBiZSB0YWtlbiBpbiByZWxpYW5jZSBvbiBp dCBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5 IGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCBhbmQgdGhlbiBkZWxldGUgdGhlIGUtbWFpbCBh bmQgYWxsIGF0dGFjaG1lbnRzIGFuZCBhbnkgY29waWVzIHRoZXJlb2YuDQoNCihjKTIwbWY1MA0K --_000_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjIuMGNtIDQyLjVwdCAyLjBjbSAzLjBjbTt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlJVIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFsbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+RXhwbGFpbiBwbGVhc2UsIHdoZXJlIEkgY2FuIGRpc2FibGUgZm9yIGNsdXN0ZXIgdGhp cyB0aHJlc2hvbGQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlVzZWQgbWVtb3J5IG9mIGhvc3QgKioqIFs5OCVdIGV4Y2VlZGVk IGRlZmluZWQgdGhyZXNob2xkIFs5NSVdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlJVIj7QktCw0YHQuNC70LjQuSDQm9Cw0LzRi9C6 0LjQvTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpSVSI+0KHRgtCw0YDR iNC40Lkg0LjQvdC20LXQvdC10YAg0L/QviDRjdC60YHQv9C70YPQsNGC0LDRhtC40Lgg0YHQtdGA 0LLQuNGB0L3Ri9GFINC/0LvQsNGC0YTQvtGA0Lw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpSVSI+0K3QutGB0L/Qu9GD0LDRgtCw0YbQuNGPINGB0LXRgtC4PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6UlUiPtCh0YLQvtC70LjRh9C90YvQuSDRhNC40LvQuNCw 0Lsg0J/QkNCeIMKr0JzQtdCz0LDQpNC+0L3CuzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOlJVIj4mIzQzOzcgKDkyNikgNTAwLTMzMDg8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpSVSI+PGltZyB3aWR0aD0iMjg1IiBoZWln aHQ9IjU0IiBpZD0i0KDQuNGB0YPQvdC+0LpfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5n QDAxRDJBODhBLjc2NDhBMDMwIiBhbHQ9ItCc0LXQs9Cw0KTQvtC9INC70L7Qs9C+JiM0MzvQt9C9 0LDQuiDQoNCj0KEgQjJDIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFj ZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQrQmNC90YTQvtGA0LzQsNGG0LjR jyDQsiDRjdGC0L7QvCDRgdC+0L7QsdGJ0LXQvdC40Lgg0L/RgNC10LTQvdCw0LfQvdCw0YfQtdC9 0LAg0LjRgdC60LvRjtGH0LjRgtC10LvRjNC90L4g0LTQu9GPINC60L7QvdC60YDQtdGC0L3Ri9GF INC70LjRhiwg0LrQvtGC0L7RgNGL0Lwg0L7QvdCwINCw0LTRgNC10YHQvtCy0LDQvdCwLiDQkiDR gdC+0L7QsdGJ0LXQvdC40Lgg0LzQvtC20LXRgiDRgdC+0LTQtdGA0LbQsNGC0YzRgdGPINC60L7Q vdGE0LjQtNC10L3RhtC40LDQu9GM0L3QsNGPINC40L3RhNC+0YDQvNCw0YbQuNGPLCDQutC+0YLQ vtGA0LDRjyDQvdC1INC80L7QttC10YIg0LHRi9GC0Ywg0YDQsNGB0LrRgNGL0YLQsCDQuNC70Lgg 0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdCwINC60LXQvC3Qu9C40LHQviwg0LrRgNC+0LzQtSDQsNC0 0YDQtdGB0LDRgtC+0LIuINCV0YHQu9C4INCy0Ysg0L3QtSDQsNC00YDQtdGB0LDRgiDRjdGC0L7Q s9C+DQog0YHQvtC+0LHRidC10L3QuNGPLCDRgtC+INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC1 LCDQv9C10YDQtdCw0LTRgNC10YHQsNGG0LjRjywg0LrQvtC/0LjRgNC+0LLQsNC90LjQtSDQuNC7 0Lgg0YDQsNGB0L/RgNC+0YHRgtGA0LDQvdC10L3QuNC1INGB0L7QtNC10YDQttCw0L3QuNGPINGB 0L7QvtCx0YnQtdC90LjRjyDQuNC70Lgg0LXQs9C+INGH0LDRgdGC0Lgg0L3QtdC30LDQutC+0L3Q vdC+INC4INC30LDQv9GA0LXRidC10L3Qvi4g0JXRgdC70Lgg0JLRiyDQv9C+0LvRg9GH0LjQu9C4 INGN0YLQviDRgdC+0L7QsdGJ0LXQvdC40LUg0L7RiNC40LHQvtGH0L3Qviwg0L/QvtC20LDQu9GD 0LnRgdGC0LAsINC90LXQt9Cw0LzQtdC00LvQuNGC0LXQu9GM0L3QviDRgdC+0L7QsdGJ0LjRgtC1 INC+0YLQv9GA0LDQstC40YLQtdC70Y4g0L7QsSDRjdGC0L7QvCDQuCDRg9C00LDQu9C40YLQtSDR gdC+INCy0YHQtdC8INGB0L7QtNC10YDQttC40LzRi9C8DQog0YHQsNC80L4g0YHQvtC+0LHRidC1 0L3QuNC1INC4INC70Y7QsdGL0LUg0LLQvtC30LzQvtC20L3Ri9C1INC10LPQviDQutC+0L/QuNC4 INC4INC/0YDQuNC70L7QttC10L3QuNGPLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBjb21tdW5pY2F0aW9uIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQgYW5k IG90aGVycyBhdXRob3JpemVkIHRvIHJlY2VpdmUgaXQuIEl0IG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIFRoZSBjb250ZW50cyBtYXkg bm90IGJlIGRpc2Nsb3NlZA0KIG9yIHVzZWQgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGFkZHJl c3NlZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgYW55IHVzZSwg ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIGFueSBhY3Rpb24gdGFrZW4gb3Ig b21pdHRlZCB0byBiZSB0YWtlbiBpbiByZWxpYW5jZSBvbiBpdCBpcyBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbg0K IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmVzcG9uZGluZyB0byB0 aGlzIGVtYWlsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgZS1tYWlsIGFuZCBhbGwgYXR0YWNobWVudHMg YW5kIGFueSBjb3BpZXMgdGhlcmVvZi48YnI+DQo8YnI+DQooYykyMG1mNTA8YnI+DQo8L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_-- --_004_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=2130; creation-date="Wed, 29 Mar 2017 09:46:18 GMT"; modification-date="Wed, 29 Mar 2017 09:46:18 GMT" Content-ID: <image001.png(a)01D2A88A.7648A030> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAA4CAYAAAChZA4IAAAACXBIWXMAAA9hAAAPYQGoP6dpAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAB99JREFUeNrsnd114joUhZUs3q87 GE8FcSoIVDCkAsjbvJlUAKmA8Ja3QAVhKsCpYJgKxrcD3wq4liUTIx/LkiwyMOxvLc0k/PhX2trn SFbYTtBnAABwQnBd4uJU/hDgkgAATkykAhgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM1c 4RIAAEheRsP837u8RLLwx+cS9n01yN+byffSvLznZZ2/nh3jMHq4EwCAijBxIZrkZZSXsOXTffn/ OC/z/Lvr/P+nXKxSn4d0jbsCAJACxcXpd16mBgKlEkix+p1vZy7FDiIFAPDknl5Gb4UbEmLTFS52 m3ybEUQKAOAjvNvkZeh5y5EvoYJIAQCBio60h8CHUPWIgxYb/L5KPFwAP9sCAByDtyMKlCpUX11H /3oVUZnLWLL8nW/wMd/w0kGgqG095NtaX0DvVB22tSVlRx7OBUDWU94++5+0Ny5Ur3m5d/nylTzg sdwIxb2VuKgCdchX38OTJyZO/NxDD1vjAsWHcp/RmsAR6iqvoz+ZW5K8Ok9qavndgUtUVTqpWPOZ edGzm5/8RPOJuHBnh99xUfPtgdOohpY2UBdMCPad/O3dyEnqRd615+HDuDf5/h8Mr3ukuQZJ7ZrV t9GvuTpdh0Jdc4T158LUUqAST67rtTAqjiKla+Bh0QjNwr42ZY2UhrVxdB4DeeG6CsSV0vA2ys0Y 56/FsgfINAIxP1Jl4vtfNTZ+ce6xgUBP5efLyXZb4jMb5fenvMxa7uVGez3BKbooLk6mI3m8zt8W nZVIfm867j0sOkPLzsx0dG/k+eTLhuMjNJp7unmzht4ianGHVK+UyND2al9Eo1dtc/V93sMsjc/v ZfQqxdnGQQ4Lmy/EDVwmQwsXtdi7adGx+XDKI9svNImUavP7BmHZhDj5VKuq/kIjH8Ta95pn0FJh 0sA698Y/L0K7dU0khVtTBbWL0Lw6htng/Lmz+OzNEdqsdb1renZvLRtBoChgYqGQieWJZYVym6ET AH7svyxdlHqumSKA5ZT/Z8I9hkSY1IUnwpGG+3MW+4wb8gY/GM89HfKNuJelA0zQZi8OG5EYSse+ qqQVutaZsOh0LTrxJpH6T4YeEyU/Qj88KBp5WLOKeneiwhO7Mw83YeGQwJ0Sx54poVZcEyk61Np2 Onpuq19GVMVKNHZ9qUmwJ8V9q0/a69tWFvBXYOuGxh1de9MxGNe7a21jpw/YxEWlZzMnSkwdUG/c sxTpTOkB2m8WnZS2ZWthwbPWEUCR9H8k3onQZi8INW1wJkLZ0+ZIXkZLRZi4m5gpJx4RFtIl5Ink 6JqJ2xh4vGAx4UoyeW5r5fynjE5ufyZRQ1jdds0SwqFFrHl6yTT//BQt+6Jd1EkcR9vo3kr5PSDc RFzr2U3nVanbFmJnUnz1LNT2FhqxDVsTzn6e/I5qzrQZm/xbgnYKHHisjEQPPnvn1629b71iTysN MiBCwMUZPdIR18Ksargm8jXN50/nvro9TS7CT2YhUgCY4T7Zdrvv1EWZMLt8c6fO0mRlzpXiNqoT sqj5Q67hUMa6Jp3t4/Nh7RjE8L56XFX6yoS0reJ84iJMdMlNCdGfW1auf87Q7oPzZPMndtouUnym uchNhIoDSRidz3Ht9befbCWpfItpOFmdjrFSRIoLzU+Zz3uvuKAvROjcr3znjtFTBZYtrmrI6KQ4 JcqhhUN70o62imPfoN2eHQn7vAeLvTg60xnnq1rDEI4jaPncaSIa7LjDFsb7kRLxEPCW/IyYEb6R Rd1fVHnvjdGTYcWDxof8qrkjOkRUmTfaeHBJvHvazpaoq6nBa9Yhp+kfYniWrinQOJGk4wOmgcUs 6G3HvNfYw03i518O/T9IofEZTvHzo2aurwnBeZNzoepOViTyp0Rom3qaLgHOizWzX71Add+3RfsT neObFKyBfK3snNdMLM+UKSsm/LDdoZmTEoLQNmLX1UVVnUVbcR9Bo2dsLw+eo6NKPewa7x+VEY39 VrqezIM4LWVF2BL3ImV03o9XAr4I/u6giCU5hmQ4By4PUae6dE6rvUEQcyETmRrI9ukhsf1F5bWZ Jn3hzUmVlXrcqK72i+P9qRHAiWOYuiDOn29rVhHyWVGEewkVMb1TcgGpst9UXkcTN/rI9EuztLF0 WswQ/C0smPvKIV9q6YbqfLuPR8VCJb1S1jvrdm8uUmJy5wNxcnynLivurZj/xd9NoGbHJwbnzx9X SRSh4SN5z7UL/9FbrSs3alYTKdfHgISFHkj3NLHsGLCYHtwUHwwbMbcEOo8g/pX1O5ZiNJUThbfs Y1WQeWXycCzr3qPL4fYarH+iOblMNvRA9v4LTW6DC9G74hbY3iqKhuZyoVJN2JJqQr2QcE2JxX6f WD3xGBi6wsT4OM1D8EeZi+Jif6NxVu9M5PHWLedmc11ShIxnzQNzX51zavBaoBiae9c8MhYpA+BS MV8wciAfq9p1SC88uB4m/qQVAJcc9n2MUB+LTgIFkQIAQnVMoeosUBApAEApVHwKTeppi+WfsPMi fhApAIDPuX5C8DxOcenh7gAApFCJuX58Wo2YE8hH8U3m4nEHxkeOF8dY6RWjewCAZj6eqqBWCBHz AbEENQAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0Y7fb9fMS4EoAAE5MmwKuT/yHXfEDAACcnoHa/S/A ANCM57qVhzX7AAAAAElFTkSuQmCC --_004_78c01f9d8162434bbebbfe6a92222ba0vlgums05Megafonru_--

1 0

How to passthrough GPU to windows guest
by yimao 29 Mar '17

29 Mar '17

Hi, I'm trying to passthrough gpu card to windows 7 guest, but I got the error code 43. I use ovirt node: ovirt-node-ng-installer-ovirt-4.1-2017032304.iso and ovirt-engine-appliance-4.1-20170322.1.el7.centos.noarch.rpm I have added options "intel_iommu=on rdblacklist=nouveau pci-stub.ids=10de:1380,10de:0fbc" to the grub.conf and attached these devices to the guest. After I have installed the gpu's driver, I got the error code 43. Did I miss something? Any pointers or suggestions would be greatly appreciated. Thanks in advance. Yiimao Yang.

2 6

Introduction and initial help needed
by Abdullah 28 Mar '17

28 Mar '17

Hello It is Abdullah. I have been using different virtualization platform for a long time. Currently started working on oVirt. Initially I need some help with an issue: on the ovirt engine, I can add an ovirt-node 4.1 host but I cannot add a centOS 7.3 ovirt node. I have successfully installed the vdsm on the centos, but every time I try to add this host to engine, I get the following error: Command returned failure code 1 during SSH session 'root at my_host <http://lists.ovirt.org/mailman/listinfo/users>'. however an ovirt-node host installed from the ovirt-node iso works without any issue on the engine. Can anyone tell me what log output I need to provide to find out the reason. Regards Abdullah -- ___________________ With Best Regards *Abdullah Mohammad Manjurul Islam* *Cell:* *+880 1730 982562* *Email:* digitalrevolution(a)gmail.com ; islammanjurul(a)yahoo.com *Address:* 958/1 Outer Circular Road, Rajarbagh, Dhaka-1217, Bangladesh *Cisco® CCNA**™* *VMware**®** VCP6-DCV*™ *Disclaimer:** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.*

2 1

Setting up hosted engine appliance on a bonded interface
by Bryan Sockel 28 Mar '17

28 Mar '17

Hi, I am attempting to deploy an appliance to a bonded interface, and i getting this error when it attempts to setup the bridge: [ ERROR ] Failed to execute stage 'Misc configuration': Failed to setup networks {'ovirtmgmt': {'bonding': 'bond0', 'ipaddr': u'10.20.101.181', 'netmask': u'255.255.255.0', 'defaultRoute': True, 'gateway': u'10.20.101.1'}}. Error code: "-32603" message: "Attempt to call function: <bound method Global.setupNetworks of <API.Global object at 0x39c9110>> with arguments: ({u'ovirtmgmt': {u'bonding': u'bond0', u'ipaddr': u'10.20.101.181', u'netmask': u'255.255.255.0', u'defaultRoute': True, u'gateway': u'10.20.101.1'}}, {}, {u'connectivityCheck': False}) error: 'NoneType' object is not iterable" Is it possible to deploy an appliance to a network bond? My Network guy has configured my ports in the switch so i can connect via bonded links. however, if the interfaces are not bonded, it will suspend the links.

3 3

How to re-initialize storage?
by Peter Wood 28 Mar '17

28 Mar '17

Hi, I inherited a small oVirt cluster with 3 nodes using iSCSI storage. The LUNs used by the oVirt nodes were also accessible by some VMware nodes. By mistake an action was started on VMware to initialize and start using the same LUNs, which it happily did. This rendered the storage no longer usable by oVirt nodes. All VMs went down, their image files no longer accessible, the whole cluster became unusable without access to the shared storage. We have recovered from backups and moved the VMs to another cluster and now I want to get this oVirt cluster back up and running. I'm not an oVirt expert so everything I tried was through the web interface and everything failed because storage is not accessible. I can't remove VMs, I can't remove nodes, I can't remove the storage domain. What is the right approach to destroy the cluster and rebuild it and re-initialize the storage? Even better if I can just remove all VMs from the inventory and somehow tell it to make the storage LUNs usable again? Any help is highly appreciated? Thank you, -- Peter

5 4

problems with serial console in 4.1.1
by Gianluca Cecchi 28 Mar '17

28 Mar '17

Hello, trying serial console in 4.1.1 I have some problems. I have not understood if it depends on my client, or the guest or oVirt... My client is Fedora 25 updated My guest is a CentOS 7.3 VM updated (my latest successful attempts were when in 7.2) My oVirt is 4.1.1 (my latest successful attempts were when in 4.0.x) Some tests $ ssh -i .ssh/id_dsa.pub ovirt-vmconsole@ovmgr1 -p 2222 Available Serial Consoles: 00 c7service[2e571c77-bae1-4c1c-bf98-effaf9fed741] 01 c7testovn1[63818176-cfb5-4a00-912d-ce0e812be76c] 02 c7testovn2[f00c8f30-a658-4a18-bf85-3b523de93183] 03 dbatest6[633b58b6-5e99-491b-a312-0976d4e8d979] 04 nas4free[6b9013d1-1837-4b0f-aa34-c9130d4f1229] 05 raclab1[1775d180-288d-4116-af1e-d90b2989cb8a] 06 raclab2[852aa8b1-a3e2-4658-be91-0ab51b6b7260] SELECT> 00 and it stays here without giving the os prompt. In 7.3 guest I have VirtIO serial console enabled and this situation [root@c7service ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.10.0-514.6.1.el7.x86_64 root=/dev/mapper/cl-root ro rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet console=ttyS0 [root@c7service ~]# [root@c7service ~]# ps -ef|grep agetty root 718 1 0 11:15 ttyS0 00:00:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220 root 1760 1541 0 11:29 pts/0 00:00:00 grep --color=auto agetty [root@c7service ~]# So it seems ok. I have not understood the error I get connecting this way: $ ssh -i .ssh/id_dsa.pub ovirt-vmconsole@ovmgr1 -p 2222 connect --vm-name c7service ERROR: No pty support, please enable at client side $ What is "client" in the error message, my Fedora 25..? At engine side I have: [root@ovmgr1 ovirt-engine]# systemctl status ovirt-vmconsole-proxy-sshd.service -l ● ovirt-vmconsole-proxy-sshd.service - oVirt VM Console SSH server daemon Loaded: loaded (/usr/lib/systemd/system/ovirt-vmconsole-proxy-sshd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2017-03-28 11:00:26 CEST; 33min ago Main PID: 1117 (sshd) CGroup: /system.slice/ovirt-vmconsole-proxy-sshd.service └─1117 /usr/sbin/sshd -f /usr/share/ovirt-vmconsole/ovirt-vmconsole-proxy/ovirt-vmconsole-proxy-sshd/sshd_config -D Mar 28 11:19:44 ovmgr1.mydomain sshd[2779]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 34947 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:19:52 ovmgr1.mydomain sshd[2796]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 16456 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:19:53 ovmgr1.mydomain sshd[2808]: Received disconnect from 10.4.170.225: 11: disconnected by user Mar 28 11:20:02 ovmgr1.mydomain sshd[2824]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 5769 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:20:14 ovmgr1.mydomain sshd[2855]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 52441 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:20:24 ovmgr1.mydomain sshd[2882]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 33724 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:20:24 ovmgr1.mydomain sshd[2894]: Received disconnect from 10.4.170.225: 11: disconnected by user Mar 28 11:20:36 ovmgr1.mydomain sshd[2900]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 64049 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:21:26 ovmgr1.mydomain sshd[2955]: Accepted publickey for ovirt-vmconsole from 10.4.170.225 port 3521 ssh2: DSA 3d:d4:5b:94:b9:9e:4b:46:14:b2:4a:05:03:9b:05:d6 Mar 28 11:21:27 ovmgr1.mydomain sshd[2967]: Received disconnect from 10.4.170.225: 11: disconnected by user Thanks, Gianluca

2 2