From Simon.Barrett at tradingscreen.com Tue Aug 25 11:41:26 2015 Content-Type: multipart/mixed; boundary="===============1168547338657134914==" MIME-Version: 1.0 From: Simon Barrett To: users at ovirt.org Subject: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? Date: Mon, 24 Aug 2015 14:01:45 +0000 Message-ID: --===============1168547338657134914== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable I'm running into a problem with my upgrades to oVirt 3.5.3 and wanted to ch= =3D eck if the following is a known issue. I have multiple vlan tagged interfaces configured. The files are being gen= =3D erated as expected by vdsm. The vlan 108 interface below is used by the ovi= =3D rtmgmt bridge. The uatdev_ben, bond0.192, dev_office, bond0.124 interface d= =3D efinitions all have ONBOOT=3D3Dno. root(a)host> grep -i onboot ifcfg* | grep -v bak ifcfg-bond0:ONBOOT=3D3Dyes ifcfg-bond0.108:ONBOOT=3D3Dyes ifcfg-bond0.124:ONBOOT=3D3Dno ifcfg-bond0.192:ONBOOT=3D3Dno ifcfg-dev_office:ONBOOT=3D3Dno ifcfg-eth0:ONBOOT=3D3Dyes ifcfg-eth1:ONBOOT=3D3Dyes ifcfg-eth2:ONBOOT=3D3Dno ifcfg-eth3:ONBOOT=3D3Dno ifcfg-lo:ONBOOT=3D3Dyes ifcfg-ovirtmgmt:ONBOOT=3D3Dyes ifcfg-uatdev_ben:ONBOOT=3D3Dno The persistence configuration files are where they should be (I think): root(a)host> ls -l /var/lib/vdsm/persistence/netconf/nets/ total 12 -rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office -rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt -rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben If I were to do a "service network restart" on the node, the uatdev_ben, de= =3D v_office, bond0.124 & bond0.192 are removed and then not restored as the "O= =3D NBOOT=3D3Dno". I assumed that vdsmd would re-create the dev_office and uatd= ev=3D _ben interfaces so restarted vdsmd but they were not restored. I tried a "v= =3D dsm-tool restore-nets" to see if that would restore the interfaces but no j= =3D oy. Am I missing something? Is there another method I should use to recover the= =3D missing interfaces? Should the ifcfg files all be configured with "ONBOOT= =3D =3D3Dyes" just in case someone does run a "service network restart"? My oVirt nodes are CentOS 6.5, I'm not using the node iso. Many thanks in advance for any assistance. Regards, Simon Barrett --_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

I’m running into a problem with my upgrades = to=3D oVirt 3.5.3 and wanted to check if the following is a known issue.

I have multiple vlan tagged interfaces confi= gu=3D red. The files are being generated as expected by vdsm. The vlan 108 interf= =3D ace below is used by the ovirtmgmt bridge. The uatdev_ben, bond0.192, dev_o= =3D ffice, bond0.124 interface definitions all have ONBOOT=3D3Dno.

root(a)host> gre= p -i o=3D nboot ifcfg* | grep -v bak

ifcfg-bond0:ONBOOT= =3D3Dye=3D s

ifcfg-bond0.108:ONB= OOT=3D =3D3Dyes

ifcfg-bond0.124:ONB= OOT=3D =3D3Dno

ifcfg-bond0.192:ONB= OOT=3D =3D3Dno

ifcfg-dev_office:ON= BOOT=3D =3D3Dno

ifcfg-eth0:ONBOOT= =3D3Dyes=3D

ifcfg-eth1:ONBOOT= =3D3Dyes=3D

ifcfg-eth2:ONBOOT= =3D3Dno<=3D o:p>

ifcfg-eth3:ONBOOT= =3D3Dno<=3D o:p>

ifcfg-lo:ONBOOT=3D3= Dyes

ifcfg-ovirtmgmt:ONB= OOT=3D =3D3Dyes

ifcfg-uatdev_ben:ON= BOOT=3D =3D3Dno

The persistence configuration files are where they= s=3D hould be (I think):

root(a)host> ls = -l /va=3D r/lib/vdsm/persistence/netconf/nets/

total 12=

-rw-r--r-- 1 root r= oot =3D 121 Aug 24 22:44 dev_office

-rw-r--r-- 1 root r= oot =3D 173 Aug 24 22:44 ovirtmgmt

-rw-r--r-- 1 root r= oot =3D 121 Aug 24 22:44 uatdev_ben

If I were to do a “service network restart&#= 82=3D 21; on the node, the uatdev_ben, dev_office, bond0.124 & bond0.192 are = =3D removed and then not restored as the “ONBOOT=3D3Dno”. I assumed= t=3D hat vdsmd would re-create the dev_office and uatdev_ben interfaces so restarted vdsmd but they were not restored. I tried a “vdsm-tool = =3D restore-nets” to see if that would restore the interfaces but no joy.= =3D

Am I missing something? Is there another method I = sh=3D ould use to recover the missing interfaces? Should the ifcfg files all be c= =3D onfigured with “ONBOOT=3D3Dyes” just in case someone does run a= &=3D #8220;service network restart”?

My oVirt nodes are CentOS 6.5, I’m not using= t=3D he node iso.

Many thanks in advance for any assistance.

Regards,

Simon Barrett

--_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_-- --===============1168547338657134914== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1fMDAwX0Q4NkM0OERGODgwMDE2NEJCRTUwQjg3NjIzRjdBQzk1ODBBMTY0NTlsbjJ3aW8wMDFk ZXZ0cmFfCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUKCkknbSBydW5uaW5nIGludG8g YSBwcm9ibGVtIHdpdGggbXkgdXBncmFkZXMgdG8gb1ZpcnQgMy41LjMgYW5kIHdhbnRlZCB0byBj aD0KZWNrIGlmIHRoZSBmb2xsb3dpbmcgaXMgYSBrbm93biBpc3N1ZS4KCkkgaGF2ZSAgbXVsdGlw bGUgdmxhbiB0YWdnZWQgaW50ZXJmYWNlcyBjb25maWd1cmVkLiBUaGUgZmlsZXMgYXJlIGJlaW5n IGdlbj0KZXJhdGVkIGFzIGV4cGVjdGVkIGJ5IHZkc20uIFRoZSB2bGFuIDEwOCBpbnRlcmZhY2Ug YmVsb3cgaXMgdXNlZCBieSB0aGUgb3ZpPQpydG1nbXQgYnJpZGdlLiBUaGUgdWF0ZGV2X2Jlbiwg Ym9uZDAuMTkyLCBkZXZfb2ZmaWNlLCBib25kMC4xMjQgaW50ZXJmYWNlIGQ9CmVmaW5pdGlvbnMg YWxsIGhhdmUgT05CT09UPTNEbm8uCgpyb290QGhvc3Q+IGdyZXAgLWkgb25ib290IGlmY2ZnKiB8 IGdyZXAgLXYgYmFrCmlmY2ZnLWJvbmQwOk9OQk9PVD0zRHllcwppZmNmZy1ib25kMC4xMDg6T05C T09UPTNEeWVzCmlmY2ZnLWJvbmQwLjEyNDpPTkJPT1Q9M0RubwppZmNmZy1ib25kMC4xOTI6T05C T09UPTNEbm8KaWZjZmctZGV2X29mZmljZTpPTkJPT1Q9M0RubwppZmNmZy1ldGgwOk9OQk9PVD0z RHllcwppZmNmZy1ldGgxOk9OQk9PVD0zRHllcwppZmNmZy1ldGgyOk9OQk9PVD0zRG5vCmlmY2Zn LWV0aDM6T05CT09UPTNEbm8KaWZjZmctbG86T05CT09UPTNEeWVzCmlmY2ZnLW92aXJ0bWdtdDpP TkJPT1Q9M0R5ZXMKaWZjZmctdWF0ZGV2X2JlbjpPTkJPT1Q9M0RubwoKVGhlIHBlcnNpc3RlbmNl IGNvbmZpZ3VyYXRpb24gZmlsZXMgYXJlIHdoZXJlIHRoZXkgc2hvdWxkIGJlIChJIHRoaW5rKToK CnJvb3RAaG9zdD4gbHMgLWwgL3Zhci9saWIvdmRzbS9wZXJzaXN0ZW5jZS9uZXRjb25mL25ldHMv CnRvdGFsIDEyCi1ydy1yLS1yLS0gMSByb290IHJvb3QgMTIxIEF1ZyAyNCAyMjo0NCBkZXZfb2Zm aWNlCi1ydy1yLS1yLS0gMSByb290IHJvb3QgMTczIEF1ZyAyNCAyMjo0NCBvdmlydG1nbXQKLXJ3 LXItLXItLSAxIHJvb3Qgcm9vdCAxMjEgQXVnIDI0IDIyOjQ0IHVhdGRldl9iZW4KCklmIEkgd2Vy ZSB0byBkbyBhICJzZXJ2aWNlIG5ldHdvcmsgcmVzdGFydCIgb24gdGhlIG5vZGUsIHRoZSB1YXRk ZXZfYmVuLCBkZT0Kdl9vZmZpY2UsIGJvbmQwLjEyNCAmIGJvbmQwLjE5MiBhcmUgcmVtb3ZlZCBh bmQgdGhlbiBub3QgcmVzdG9yZWQgYXMgdGhlICJPPQpOQk9PVD0zRG5vIi4gSSBhc3N1bWVkIHRo YXQgdmRzbWQgd291bGQgcmUtY3JlYXRlIHRoZSBkZXZfb2ZmaWNlIGFuZCB1YXRkZXY9Cl9iZW4g aW50ZXJmYWNlcyBzbyByZXN0YXJ0ZWQgdmRzbWQgYnV0IHRoZXkgd2VyZSBub3QgcmVzdG9yZWQu IEkgdHJpZWQgYSAidj0KZHNtLXRvb2wgcmVzdG9yZS1uZXRzIiB0byBzZWUgaWYgdGhhdCB3b3Vs ZCByZXN0b3JlIHRoZSBpbnRlcmZhY2VzIGJ1dCBubyBqPQpveS4KCkFtIEkgbWlzc2luZyBzb21l dGhpbmc/IElzIHRoZXJlIGFub3RoZXIgbWV0aG9kIEkgc2hvdWxkIHVzZSB0byByZWNvdmVyIHRo ZT0KIG1pc3NpbmcgaW50ZXJmYWNlcz8gU2hvdWxkIHRoZSBpZmNmZyBmaWxlcyBhbGwgYmUgY29u ZmlndXJlZCB3aXRoICJPTkJPT1Q9Cj0zRHllcyIganVzdCBpbiBjYXNlIHNvbWVvbmUgZG9lcyBy dW4gYSAic2VydmljZSBuZXR3b3JrIHJlc3RhcnQiPwoKTXkgb1ZpcnQgbm9kZXMgYXJlIENlbnRP UyA2LjUsIEknbSBub3QgdXNpbmcgdGhlIG5vZGUgaXNvLgoKTWFueSB0aGFua3MgaW4gYWR2YW5j ZSBmb3IgYW55IGFzc2lzdGFuY2UuCgpSZWdhcmRzLAoKU2ltb24gQmFycmV0dAoKLS1fMDAwX0Q4 NkM0OERGODgwMDE2NEJCRTUwQjg3NjIzRjdBQzk1ODBBMTY0NTlsbjJ3aW8wMDFkZXZ0cmFfCkNv bnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJ1cy1hc2NpaSIKQ29udGVudC1UcmFuc2Zl ci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0bWwgeG1sbnM6dj0zRCJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0zRCJ1cm46c2NoZW1hcy1taWNyPQpvc29mdC1j b206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTp3b3JkIiA9CnhtbG5zOm09M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNC8xMi9vbW1sIiB4bWxucz0zRCJodHRwOj0KLy93d3cudzMub3JnL1RSL1JFQy1odG1s NDAiPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0zRCJDb250ZW50LVR5cGUiIGNvbnRlbnQ9M0Qi dGV4dC9odG1sOyBjaGFyc2V0PTNEdXMtYXNjaWkiPQo+CjxtZXRhIG5hbWU9M0QiR2VuZXJhdG9y IiBjb250ZW50PTNEIk1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4KPHN0eWxl PjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNh bWJyaWEgTWF0aCI7CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9Ci8q IFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEx LjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOwoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxT dHlsZTE3Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOwoJY29sb3I6d2luZG93dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsKCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0zRCJlZGl0IiBzcGlk bWF4PTNEIjEwMjYiIC8+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pgo8bzpzaGFwZWxheW91dCB2OmV4dD0zRCJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9M0QiZWRpdCIg ZGF0YT0zRCIxIiAvPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CjwvaGVhZD4K PGJvZHkgbGFuZz0zRCJFTi1HQiIgbGluaz0zRCIjMDU2M0MxIiB2bGluaz0zRCIjOTU0RjcyIj4K PGRpdiBjbGFzcz0zRCJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPkkmIzgy MTc7bSBydW5uaW5nIGludG8gYSBwcm9ibGVtIHdpdGggbXkgdXBncmFkZXMgdG89CiBvVmlydCAz LjUuMyBhbmQgd2FudGVkIHRvIGNoZWNrIGlmIHRoZSBmb2xsb3dpbmcgaXMgYSBrbm93biBpc3N1 ZS48bzpwPjwvbz0KOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPkkgaGF2ZSZuYnNwOyBtdWx0aXBsZSB2bGFu IHRhZ2dlZCBpbnRlcmZhY2VzIGNvbmZpZ3U9CnJlZC4gVGhlIGZpbGVzIGFyZSBiZWluZyBnZW5l cmF0ZWQgYXMgZXhwZWN0ZWQgYnkgdmRzbS4gVGhlIHZsYW4gMTA4IGludGVyZj0KYWNlIGJlbG93 IGlzIHVzZWQgYnkgdGhlIG92aXJ0bWdtdCBicmlkZ2UuIFRoZSB1YXRkZXZfYmVuLCBib25kMC4x OTIsIGRldl9vPQpmZmljZSwgYm9uZDAuMTI0IGludGVyZmFjZSBkZWZpbml0aW9ucwogYWxsIGhh dmUgT05CT09UPTNEbm8uPG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCIgc3R5bGU9M0QibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5yb290QGhvc3QmZ3Q7IGdyZXAgLWkgbz0KbmJvb3QgaWZjZmcqIHwgZ3Jl cCAtdiBiYWs8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIiBzdHlsZT0zRCJt YXJnaW4tbGVmdDozNi4wcHQiPmlmY2ZnLWJvbmQwOk9OQk9PVD0zRHllPQpzPG86cD48L286cD48 L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCIgc3R5bGU9M0QibWFyZ2luLWxlZnQ6MzYuMHB0Ij5p ZmNmZy1ib25kMC4xMDg6T05CT09UPQo9M0R5ZXM8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0Qi TXNvTm9ybWFsIiBzdHlsZT0zRCJtYXJnaW4tbGVmdDozNi4wcHQiPmlmY2ZnLWJvbmQwLjEyNDpP TkJPT1Q9Cj0zRG5vPG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCIgc3R5bGU9 M0QibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pZmNmZy1ib25kMC4xOTI6T05CT09UPQo9M0RubzxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiIHN0eWxlPTNEIm1hcmdpbi1sZWZ0OjM2 LjBwdCI+aWZjZmctZGV2X29mZmljZTpPTkJPT1Q9Cj0zRG5vPG86cD48L286cD48L3A+CjxwIGNs YXNzPTNEIk1zb05vcm1hbCIgc3R5bGU9M0QibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pZmNmZy1ldGgw Ok9OQk9PVD0zRHllcz0KPG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCIgc3R5 bGU9M0QibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pZmNmZy1ldGgxOk9OQk9PVD0zRHllcz0KPG86cD48 L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCIgc3R5bGU9M0QibWFyZ2luLWxlZnQ6MzYu MHB0Ij5pZmNmZy1ldGgyOk9OQk9PVD0zRG5vPD0KbzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0Qi TXNvTm9ybWFsIiBzdHlsZT0zRCJtYXJnaW4tbGVmdDozNi4wcHQiPmlmY2ZnLWV0aDM6T05CT09U PTNEbm88PQpvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiIHN0eWxlPTNEIm1h cmdpbi1sZWZ0OjM2LjBwdCI+aWZjZmctbG86T05CT09UPTNEeWVzPG89CjpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9M0QiTXNvTm9ybWFsIiBzdHlsZT0zRCJtYXJnaW4tbGVmdDozNi4wcHQiPmlmY2Zn LW92aXJ0bWdtdDpPTkJPT1Q9Cj0zRHllczxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29O b3JtYWwiIHN0eWxlPTNEIm1hcmdpbi1sZWZ0OjM2LjBwdCI+aWZjZmctdWF0ZGV2X2JlbjpPTkJP T1Q9Cj0zRG5vPG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+VGhlIHBlcnNpc3RlbmNlIGNvbmZp Z3VyYXRpb24gZmlsZXMgYXJlIHdoZXJlIHRoZXkgcz0KaG91bGQgYmUgKEkgdGhpbmspOjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8 cCBjbGFzcz0zRCJNc29Ob3JtYWwiIHN0eWxlPTNEIm1hcmdpbi1sZWZ0OjM2LjBwdCI+cm9vdEBo b3N0Jmd0OyBscyAtbCAvdmE9CnIvbGliL3Zkc20vcGVyc2lzdGVuY2UvbmV0Y29uZi9uZXRzLzxv OnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiIHN0eWxlPTNEIm1hcmdpbi1sZWZ0 OjM2LjBwdCI+dG90YWwgMTI8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIiBz dHlsZT0zRCJtYXJnaW4tbGVmdDozNi4wcHQiPi1ydy1yLS1yLS0gMSByb290IHJvb3QgPQoxMjEg QXVnIDI0IDIyOjQ0IGRldl9vZmZpY2U8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9y bWFsIiBzdHlsZT0zRCJtYXJnaW4tbGVmdDozNi4wcHQiPi1ydy1yLS1yLS0gMSByb290IHJvb3Qg PQoxNzMgQXVnIDI0IDIyOjQ0IG92aXJ0bWdtdDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJN c29Ob3JtYWwiIHN0eWxlPTNEIm1hcmdpbi1sZWZ0OjM2LjBwdCI+LXJ3LXItLXItLSAxIHJvb3Qg cm9vdCA9CjEyMSBBdWcgMjQgMjI6NDQgdWF0ZGV2X2JlbjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0zRCJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3Jt YWwiPklmIEkgd2VyZSB0byBkbyBhICYjODIyMDtzZXJ2aWNlIG5ldHdvcmsgcmVzdGFydCYjODI9 CjIxOyBvbiB0aGUgbm9kZSwgdGhlIHVhdGRldl9iZW4sIGRldl9vZmZpY2UsIGJvbmQwLjEyNCAm YW1wOyBib25kMC4xOTIgYXJlID0KcmVtb3ZlZCBhbmQgdGhlbiBub3QgcmVzdG9yZWQgYXMgdGhl ICYjODIyMDtPTkJPT1Q9M0RubyYjODIyMTsuIEkgYXNzdW1lZCB0PQpoYXQgdmRzbWQgd291bGQg cmUtY3JlYXRlIHRoZSBkZXZfb2ZmaWNlIGFuZCB1YXRkZXZfYmVuIGludGVyZmFjZXMKIHNvIHJl c3RhcnRlZCB2ZHNtZCBidXQgdGhleSB3ZXJlIG5vdCByZXN0b3JlZC4gSSB0cmllZCBhICYjODIy MDt2ZHNtLXRvb2wgPQpyZXN0b3JlLW5ldHMmIzgyMjE7IHRvIHNlZSBpZiB0aGF0IHdvdWxkIHJl c3RvcmUgdGhlIGludGVyZmFjZXMgYnV0IG5vIGpveS49CjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0zRCJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3Jt YWwiPkFtIEkgbWlzc2luZyBzb21ldGhpbmc/IElzIHRoZXJlIGFub3RoZXIgbWV0aG9kIEkgc2g9 Cm91bGQgdXNlIHRvIHJlY292ZXIgdGhlIG1pc3NpbmcgaW50ZXJmYWNlcz8gU2hvdWxkIHRoZSBp ZmNmZyBmaWxlcyBhbGwgYmUgYz0Kb25maWd1cmVkIHdpdGggJiM4MjIwO09OQk9PVD0zRHllcyYj ODIyMTsganVzdCBpbiBjYXNlIHNvbWVvbmUgZG9lcyBydW4gYSAmPQojODIyMDtzZXJ2aWNlIG5l dHdvcmsgcmVzdGFydCYjODIyMTs/PG86cD48L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+TXkgb1ZpcnQg bm9kZXMgYXJlIENlbnRPUyA2LjUsIEkmIzgyMTc7bSBub3QgdXNpbmcgdD0KaGUgbm9kZSBpc28u IDxvOnA+CjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj5NYW55IHRoYW5rcyBpbiBhZHZhbmNlIGZvciBh bnkgYXNzaXN0YW5jZS48bzpwPjwvbzpwPQo+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48 L286cD48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+Cjxw IGNsYXNzPTNEIk1zb05vcm1hbCI+U2ltb24gQmFycmV0dDxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4K PC9ib2R5Pgo8L2h0bWw+CgotLV8wMDBfRDg2QzQ4REY4ODAwMTY0QkJFNTBCODc2MjNGN0FDOTU4 MEExNjQ1OWxuMndpbzAwMWRldnRyYV8tLQo= --===============1168547338657134914==-- From mburman at redhat.com Tue Aug 25 12:45:56 2015 Content-Type: multipart/mixed; boundary="===============2808598050500958311==" MIME-Version: 1.0 From: Michael Burman To: users at ovirt.org Subject: Re: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? Date: Tue, 25 Aug 2015 12:45:54 -0400 Message-ID: <1036446785.14954770.1440521154534.JavaMail.zimbra@redhat.com> In-Reply-To: D86C48DF8800164BBE50B87623F7AC9580A16459@ln2-wio-001.dev.tradingscreen.com --===============2808598050500958311== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Simon, This issue will be fixed on 3.5.4 = see - https://bugzilla.redhat.com/show_bug.cgi?id=3D1203422 On 3.5.3, vdsm generating all ifcfg-* files to ONBOOT=3DNO by default, exce= pt the management network and the interface it is attached to. In your case= bond (bond0,bond.108 and the slaves). - You can configure your ifcfg-* files manually to ONBOOT=3Dyes and restart= network service as a workaround for now. = Kind regards, Michael B ----- Original Message ----- From: "Simon Barrett" To: users(a)ovirt.org Sent: Monday, August 24, 2015 5:01:45 PM Subject: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? I=E2=80=99m running into a problem with my upgrades to oVirt 3.5.3 and want= ed to check if the following is a known issue. = I have multiple vlan tagged interfaces configured. The files are being gene= rated as expected by vdsm. The vlan 108 interface below is used by the ovir= tmgmt bridge. The uatdev_ben, bond0.192, dev_office, bond0.124 interface de= finitions all have ONBOOT=3Dno. = root(a)host> grep -i onboot ifcfg* | grep -v bak = ifcfg-bond0:ONBOOT=3Dyes = ifcfg-bond0.108:ONBOOT=3Dyes = ifcfg-bond0.124:ONBOOT=3Dno = ifcfg-bond0.192:ONBOOT=3Dno = ifcfg-dev_office:ONBOOT=3Dno = ifcfg-eth0:ONBOOT=3Dyes = ifcfg-eth1:ONBOOT=3Dyes = ifcfg-eth2:ONBOOT=3Dno = ifcfg-eth3:ONBOOT=3Dno = ifcfg-lo:ONBOOT=3Dyes = ifcfg-ovirtmgmt:ONBOOT=3Dyes = ifcfg-uatdev_ben:ONBOOT=3Dno = The persistence configuration files are where they should be (I think): = root(a)host> ls -l /var/lib/vdsm/persistence/netconf/nets/ = total 12 = -rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office = -rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt = -rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben = If I were to do a =E2=80=9Cservice network restart=E2=80=9D on the node, th= e uatdev_ben, dev_office, bond0.124 & bond0.192 are removed and then not re= stored as the =E2=80=9CONBOOT=3Dno=E2=80=9D. I assumed that vdsmd would re-= create the dev_office and uatdev_ben interfaces so restarted vdsmd but they= were not restored. I tried a =E2=80=9Cvdsm-tool restore-nets=E2=80=9D to s= ee if that would restore the interfaces but no joy. = Am I missing something? Is there another method I should use to recover the= missing interfaces? Should the ifcfg files all be configured with =E2=80= =9CONBOOT=3Dyes=E2=80=9D just in case someone does run a =E2=80=9Cservice n= etwork restart=E2=80=9D? = My oVirt nodes are CentOS 6.5, I=E2=80=99m not using the node iso. = Many thanks in advance for any assistance. = Regards, = Simon Barrett = _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- = Michael Burman RedHat Israel, RHEV-M QE Network Team Mobile: 054-5355725 IRC: mburman --===============2808598050500958311==-- From ibarkan at redhat.com Tue Sep 1 08:12:22 2015 Content-Type: multipart/mixed; boundary="===============4890745207900233145==" MIME-Version: 1.0 From: Ido Barkan To: users at ovirt.org Subject: Re: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? Date: Tue, 01 Sep 2015 15:12:19 +0300 Message-ID: In-Reply-To: 1036446785.14954770.1440521154534.JavaMail.zimbra@redhat.com --===============4890745207900233145== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Simon. In the meantime (until 3.5.4 is out) you can run "vdsm-tool restore-nets --force" to solve this after "service network restart". Vdsm will skip restoration if this was done since last boot. The --force flags will skip this check. Ido On Tue, Aug 25, 2015 at 7:45 PM, Michael Burman wrot= e: > Hi Simon, > > This issue will be fixed on 3.5.4 > see - https://bugzilla.redhat.com/show_bug.cgi?id=3D1203422 > > On 3.5.3, vdsm generating all ifcfg-* files to ONBOOT=3DNO by default, ex= cept the management network and the interface it is attached to. In your ca= se bond (bond0,bond.108 and the slaves). > - You can configure your ifcfg-* files manually to ONBOOT=3Dyes and resta= rt network service as a workaround for now. > > Kind regards, > Michael B > > ----- Original Message ----- > From: "Simon Barrett" > To: users(a)ovirt.org > Sent: Monday, August 24, 2015 5:01:45 PM > Subject: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? > > > > I=E2=80=99m running into a problem with my upgrades to oVirt 3.5.3 and wa= nted to check if the following is a known issue. > > > > I have multiple vlan tagged interfaces configured. The files are being ge= nerated as expected by vdsm. The vlan 108 interface below is used by the ov= irtmgmt bridge. The uatdev_ben, bond0.192, dev_office, bond0.124 interface = definitions all have ONBOOT=3Dno. > > > > root(a)host> grep -i onboot ifcfg* | grep -v bak > > ifcfg-bond0:ONBOOT=3Dyes > > ifcfg-bond0.108:ONBOOT=3Dyes > > ifcfg-bond0.124:ONBOOT=3Dno > > ifcfg-bond0.192:ONBOOT=3Dno > > ifcfg-dev_office:ONBOOT=3Dno > > ifcfg-eth0:ONBOOT=3Dyes > > ifcfg-eth1:ONBOOT=3Dyes > > ifcfg-eth2:ONBOOT=3Dno > > ifcfg-eth3:ONBOOT=3Dno > > ifcfg-lo:ONBOOT=3Dyes > > ifcfg-ovirtmgmt:ONBOOT=3Dyes > > ifcfg-uatdev_ben:ONBOOT=3Dno > > > > The persistence configuration files are where they should be (I think): > > > > root(a)host> ls -l /var/lib/vdsm/persistence/netconf/nets/ > > total 12 > > -rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office > > -rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt > > -rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben > > > > If I were to do a =E2=80=9Cservice network restart=E2=80=9D on the node, = the uatdev_ben, dev_office, bond0.124 & bond0.192 are removed and then not = restored as the =E2=80=9CONBOOT=3Dno=E2=80=9D. I assumed that vdsmd would r= e-create the dev_office and uatdev_ben interfaces so restarted vdsmd but th= ey were not restored. I tried a =E2=80=9Cvdsm-tool restore-nets=E2=80=9D to= see if that would restore the interfaces but no joy. > > > > Am I missing something? Is there another method I should use to recover t= he missing interfaces? Should the ifcfg files all be configured with =E2=80= =9CONBOOT=3Dyes=E2=80=9D just in case someone does run a =E2=80=9Cservice n= etwork restart=E2=80=9D? > > > > My oVirt nodes are CentOS 6.5, I=E2=80=99m not using the node iso. > > > > Many thanks in advance for any assistance. > > > > Regards, > > > > Simon Barrett > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > -- > Michael Burman > RedHat Israel, RHEV-M QE Network Team > > Mobile: 054-5355725 > IRC: mburman > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- = Thanks, Ido Barkan --===============4890745207900233145==-- From Simon.Barrett at tradingscreen.com Tue Sep 1 09:02:44 2015 Content-Type: multipart/mixed; boundary="===============0490886885836592465==" MIME-Version: 1.0 From: Simon Barrett To: users at ovirt.org Subject: Re: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? Date: Tue, 01 Sep 2015 13:02:32 +0000 Message-ID: In-Reply-To: CAFmWiaSN86ZOaWPOGc3YO4vyeQr4BQK3MzT=HOJG_rNjLVOBUQ@mail.gmail.com --===============0490886885836592465== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks for the info. Sadly, I'm seeing some inconsistency between different= oVirt nodes as to how management interfaces are being handled. On one host= , the ifcfg-bond0, ifcfg-eth0, ifcfg-eth1 interface files that the manageme= nt interface is dependent on are being set with "ONBOOT=3Dno". The --force = on the restore-nets just re-instates those files with the incorrect "ONBOOT= =3Dno" configuration. On another host those same interfaces are left as ONB= OOT=3Dyes. I'm still trying to work out what the differences are between the two hosts= . I was also looking to see if I could use vdsClient to manually add the co= nfig for ifcfg-bond0, ifcfg-eth0, ifcfg-eth1 so at least vdsm would know ab= out them and apply the correct configuration. Not sure if this is a sensibl= e approach or not. Thanks, Simon -----Original Message----- From: Ido Barkan [mailto:ibarkan(a)redhat.com] = Sent: 01 September 2015 13:12 To: Michael Burman Cc: Simon Barrett ; users(a)ovirt.org Subject: Re: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issu= es? Hi Simon. In the meantime (until 3.5.4 is out) you can run "vdsm-tool restore-nets --= force" to solve this after "service network restart". Vdsm will skip restoration if this was done since last boot. The --force fl= ags will skip this check. Ido On Tue, Aug 25, 2015 at 7:45 PM, Michael Burman wrot= e: > Hi Simon, > > This issue will be fixed on 3.5.4 > see - https://bugzilla.redhat.com/show_bug.cgi?id=3D1203422 > > On 3.5.3, vdsm generating all ifcfg-* files to ONBOOT=3DNO by default, ex= cept the management network and the interface it is attached to. In your ca= se bond (bond0,bond.108 and the slaves). > - You can configure your ifcfg-* files manually to ONBOOT=3Dyes and resta= rt network service as a workaround for now. > > Kind regards, > Michael B > > ----- Original Message ----- > From: "Simon Barrett" > To: users(a)ovirt.org > Sent: Monday, August 24, 2015 5:01:45 PM > Subject: [ovirt-users] oVirt 3.5.3 and Network Unified Persistence issues? > > > > I=E2=80=99m running into a problem with my upgrades to oVirt 3.5.3 and wa= nted to check if the following is a known issue. > > > > I have multiple vlan tagged interfaces configured. The files are being ge= nerated as expected by vdsm. The vlan 108 interface below is used by the ov= irtmgmt bridge. The uatdev_ben, bond0.192, dev_office, bond0.124 interface = definitions all have ONBOOT=3Dno. > > > > root(a)host> grep -i onboot ifcfg* | grep -v bak > > ifcfg-bond0:ONBOOT=3Dyes > > ifcfg-bond0.108:ONBOOT=3Dyes > > ifcfg-bond0.124:ONBOOT=3Dno > > ifcfg-bond0.192:ONBOOT=3Dno > > ifcfg-dev_office:ONBOOT=3Dno > > ifcfg-eth0:ONBOOT=3Dyes > > ifcfg-eth1:ONBOOT=3Dyes > > ifcfg-eth2:ONBOOT=3Dno > > ifcfg-eth3:ONBOOT=3Dno > > ifcfg-lo:ONBOOT=3Dyes > > ifcfg-ovirtmgmt:ONBOOT=3Dyes > > ifcfg-uatdev_ben:ONBOOT=3Dno > > > > The persistence configuration files are where they should be (I think): > > > > root(a)host> ls -l /var/lib/vdsm/persistence/netconf/nets/ > > total 12 > > -rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office > > -rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt > > -rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben > > > > If I were to do a =E2=80=9Cservice network restart=E2=80=9D on the node, = the uatdev_ben, dev_office, bond0.124 & bond0.192 are removed and then not = restored as the =E2=80=9CONBOOT=3Dno=E2=80=9D. I assumed that vdsmd would r= e-create the dev_office and uatdev_ben interfaces so restarted vdsmd but th= ey were not restored. I tried a =E2=80=9Cvdsm-tool restore-nets=E2=80=9D to= see if that would restore the interfaces but no joy. > > > > Am I missing something? Is there another method I should use to recover t= he missing interfaces? Should the ifcfg files all be configured with =E2=80= =9CONBOOT=3Dyes=E2=80=9D just in case someone does run a =E2=80=9Cservice n= etwork restart=E2=80=9D? > > > > My oVirt nodes are CentOS 6.5, I=E2=80=99m not using the node iso. > > > > Many thanks in advance for any assistance. > > > > Regards, > > > > Simon Barrett > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > -- > Michael Burman > RedHat Israel, RHEV-M QE Network Team > > Mobile: 054-5355725 > IRC: mburman > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- Thanks, Ido Barkan --===============0490886885836592465==--