From Ryan.Groten at stantec.com Fri Jul 10 15:50:26 2015 Content-Type: multipart/mixed; boundary="===============0593452222829639813==" MIME-Version: 1.0 From: Groten, Ryan To: users at ovirt.org Subject: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Fri, 10 Jul 2015 19:45:11 +0000 Message-ID: --===============0593452222829639813== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --_000_c9bc721d3e0f454d8777b18f6154406aCD1911M21corpads_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable When I try to attach new direct lun disks, the scan takes a very long time = =3D to complete because of the number of pvs presented to my hosts (there is al= =3D ready a bug on this, related to the pvcreate command taking a very long tim= =3D e - https://bugzilla.redhat.com/show_bug.cgi?id=3D3D1217401) I discovered a workaround by setting the vdsTimeout value higher (it is 180= =3D seconds by default). I changed it to 300 seconds and now the direct lun sc= =3D an returns properly, but I'm hoping someone can warn me if this workaround = =3D is safe or if it'll cause other potential issues? I made this change yeste= =3D rday and so far so good. Thanks, Ryan --_000_c9bc721d3e0f454d8777b18f6154406aCD1911M21corpads_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

When I try to attach new direct = =3D lun disks, the scan takes a very long time to complete because of the numbe= =3D r of pvs presented to my hosts (there is already a bug on this, related to the pvcreate command taking a very long time - https://bugzilla.redhat.com/show_bug.cgi?id=3D3D1217401)

I discovered a workaround by set= =3D ting the vdsTimeout value higher (it is 180 seconds by default). I changed = =3D it to 300 seconds and now the direct lun scan returns properly, but I’m hoping someone can warn me if this workaround is safe or if = =3D it’ll cause other potential issues? I made this change yesterda= =3D y and so far so good.

Thanks,

Ryan

--_000_c9bc721d3e0f454d8777b18f6154406aCD1911M21corpads_-- --===============0593452222829639813== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1fMDAwX2M5YmM3MjFkM2UwZjQ1NGQ4Nzc3YjE4ZjYxNTQ0MDZhQ0QxOTExTTIxY29ycGFkc18K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSIKQ29udGVudC1UcmFu c2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKV2hlbiBJIHRyeSB0byBhdHRhY2ggbmV3 IGRpcmVjdCBsdW4gZGlza3MsIHRoZSBzY2FuIHRha2VzIGEgdmVyeSBsb25nIHRpbWUgPQp0byBj b21wbGV0ZSBiZWNhdXNlIG9mIHRoZSBudW1iZXIgb2YgcHZzIHByZXNlbnRlZCB0byBteSBob3N0 cyAodGhlcmUgaXMgYWw9CnJlYWR5IGEgYnVnIG9uIHRoaXMsIHJlbGF0ZWQgdG8gdGhlIHB2Y3Jl YXRlIGNvbW1hbmQgdGFraW5nIGEgdmVyeSBsb25nIHRpbT0KZSAtIGh0dHBzOi8vYnVnemlsbGEu cmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9M0QxMjE3NDAxKQoKSSBkaXNjb3ZlcmVkIGEgd29y a2Fyb3VuZCBieSBzZXR0aW5nIHRoZSB2ZHNUaW1lb3V0IHZhbHVlIGhpZ2hlciAoaXQgaXMgMTgw PQogc2Vjb25kcyBieSBkZWZhdWx0KS4gSSBjaGFuZ2VkIGl0IHRvIDMwMCBzZWNvbmRzIGFuZCBu b3cgdGhlIGRpcmVjdCBsdW4gc2M9CmFuIHJldHVybnMgcHJvcGVybHksIGJ1dCBJJ20gaG9waW5n IHNvbWVvbmUgY2FuIHdhcm4gbWUgaWYgdGhpcyB3b3JrYXJvdW5kID0KaXMgc2FmZSBvciBpZiBp dCdsbCBjYXVzZSBvdGhlciBwb3RlbnRpYWwgaXNzdWVzPyAgSSBtYWRlIHRoaXMgY2hhbmdlIHll c3RlPQpyZGF5IGFuZCBzbyBmYXIgc28gZ29vZC4KClRoYW5rcywKUnlhbgoKLS1fMDAwX2M5YmM3 MjFkM2UwZjQ1NGQ4Nzc3YjE4ZjYxNTQ0MDZhQ0QxOTExTTIxY29ycGFkc18KQ29udGVudC1UeXBl OiB0ZXh0L2h0bWw7IGNoYXJzZXQ9InVzLWFzY2lpIgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiBxdW90ZWQtcHJpbnRhYmxlCgo8aHRtbCB4bWxuczp2PTNEInVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206dm1sIiB4bWxuczpvPTNEInVybjpzY2hlbWFzLW1pY3I9Cm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIiB4bWxuczp3PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQi ID0KeG1sbnM6bT0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEy L29tbWwiIHhtbG5zPTNEImh0dHA6PQovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+CjxoZWFk Pgo8bWV0YSBodHRwLWVxdWl2PTNEIkNvbnRlbnQtVHlwZSIgY29udGVudD0zRCJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9M0R1cy1hc2NpaSI9Cj4KPG1ldGEgbmFtZT0zRCJHZW5lcmF0b3IiIGNvbnRlbnQ9 M0QiTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEtLQovKiBG b250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2VudHVyeSBHb3Ro aWMiOwoJcGFub3NlLTE6MiAxMSA1IDIgMiAyIDIgMiAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLwpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBp bjsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5OwoJY29sb3I6cHVycGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZv bnQtZmFtaWx5OiJDZW50dXJ5IEdvdGhpYyIsInNhbnMtc2VyaWYiOwoJY29sb3I6d2luZG93dGV4 dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo4 LjVpbiAxMS4waW47CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQpkaXYuV29yZFNl Y3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PTNEImVkaXQiIHNwaWRtYXg9M0QiMTAyNiIg Lz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PTNEImVkaXQiPgo8bzppZG1hcCB2OmV4dD0zRCJlZGl0IiBkYXRhPTNEIjEiIC8+ CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4KPC9oZWFkPgo8Ym9keSBsYW5nPTNE IkVOLVVTIiBsaW5rPTNEImJsdWUiIHZsaW5rPTNEInB1cnBsZSI+CjxkaXYgY2xhc3M9M0QiV29y ZFNlY3Rpb24xIj4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0zRCJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NlPQpudHVyeSBHb3RoaWMmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+V2hlbiBJIHRyeSB0byBhdHRhY2ggbmV3IGRpcmVjdCA9Cmx1biBk aXNrcywgdGhlIHNjYW4gdGFrZXMgYSB2ZXJ5IGxvbmcgdGltZSB0byBjb21wbGV0ZSBiZWNhdXNl IG9mIHRoZSBudW1iZT0KciBvZiBwdnMgcHJlc2VudGVkIHRvIG15IGhvc3RzICh0aGVyZSBpcyBh bHJlYWR5IGEgYnVnIG9uCiB0aGlzLCByZWxhdGVkIHRvIHRoZSBwdmNyZWF0ZSBjb21tYW5kIHRh a2luZyBhIHZlcnkgbG9uZyB0aW1lIC0gPGEgaHJlZj0zRD0KImh0dHBzOi8vYnVnemlsbGEucmVk aGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9M0QxMjE3NDAxIj4KaHR0cHM6Ly9idWd6aWxsYS5yZWRo YXQuY29tL3Nob3dfYnVnLmNnaT9pZD0zRDEyMTc0MDE8L2E+KTxvOnA+PC9vOnA+PC9zcGFuPQo+ PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNEImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2U9Cm50dXJ5IEdvdGhpYyZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNEIk1zb05v cm1hbCI+PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD ZT0KbnR1cnkgR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgZGlzY292ZXJl ZCBhIHdvcmthcm91bmQgYnkgc2V0PQp0aW5nIHRoZSB2ZHNUaW1lb3V0IHZhbHVlIGhpZ2hlciAo aXQgaXMgMTgwIHNlY29uZHMgYnkgZGVmYXVsdCkuIEkgY2hhbmdlZCA9Cml0IHRvIDMwMCBzZWNv bmRzIGFuZCBub3cgdGhlIGRpcmVjdCBsdW4gc2NhbiByZXR1cm5zIHByb3Blcmx5LAogYnV0IEkm IzgyMTc7bSBob3Bpbmcgc29tZW9uZSBjYW4gd2FybiBtZSBpZiB0aGlzIHdvcmthcm91bmQgaXMg c2FmZSBvciBpZiA9Cml0JiM4MjE3O2xsIGNhdXNlIG90aGVyIHBvdGVudGlhbCBpc3N1ZXM/Jm5i c3A7IEkgbWFkZSB0aGlzIGNoYW5nZSB5ZXN0ZXJkYT0KeSBhbmQgc28gZmFyIHNvIGdvb2QuPG86 cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNE ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2U9Cm50dXJ5IEdvdGhpYyZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPTNEIk1zb05vcm1hbCI+PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDZT0KbnR1cnkgR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9M0QiZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDZT0KbnR1 cnkgR290aGljJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJ5YW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4KCi0tXzAwMF9jOWJjNzIxZDNlMGY0NTRk ODc3N2IxOGY2MTU0NDA2YUNEMTkxMU0yMWNvcnBhZHNfLS0K --===============0593452222829639813==-- From laravot at redhat.com Sun Jul 12 10:44:30 2015 Content-Type: multipart/mixed; boundary="===============4277507103348611676==" MIME-Version: 1.0 From: Liron Aravot To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Sun, 12 Jul 2015 10:44:28 -0400 Message-ID: <419472736.18225265.1436712268703.JavaMail.zimbra@redhat.com> In-Reply-To: c9bc721d3e0f454d8777b18f6154406a@CD1911-M21.corp.ads --===============4277507103348611676== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Ryan Groten" > To: users(a)ovirt.org > Sent: Friday, July 10, 2015 10:45:11 PM > Subject: [ovirt-users] Concerns with increasing vdsTimeout value on engin= e? > = > = > = > When I try to attach new direct lun disks, the scan takes a very long tim= e to > complete because of the number of pvs presented to my hosts (there is > already a bug on this, related to the pvcreate command taking a very long > time - https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) > = > = > = > I discovered a workaround by setting the vdsTimeout value higher (it is 1= 80 > seconds by default). I changed it to 300 seconds and now the direct lun s= can > returns properly, but I=E2=80=99m hoping someone can warn me if this work= around is > safe or if it=E2=80=99ll cause other potential issues? I made this change= yesterday > and so far so good. > = Hi, no serious issue can be caused by that. Keep in mind though that any other operation will have that amount of time = to complete before failing on timeout - which will = cause delays before failing (as the timeout was increased for all execution= s) when not everything is operational and up as expected (as in most of the= time). I'd guess that a RFE could be opened to allow increasing the timeout of spe= cific operations if a user want to do that. thanks, Liron. > = > = > Thanks, > = > Ryan > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============4277507103348611676==-- From ofrenkel at redhat.com Sun Jul 12 12:23:43 2015 Content-Type: multipart/mixed; boundary="===============0364752813843565175==" MIME-Version: 1.0 From: Omer Frenkel To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Sun, 12 Jul 2015 12:23:41 -0400 Message-ID: <1152273860.36671251.1436718221377.JavaMail.zimbra@redhat.com> In-Reply-To: 419472736.18225265.1436712268703.JavaMail.zimbra@redhat.com --===============0364752813843565175== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Liron Aravot" > To: "Ryan Groten" > Cc: users(a)ovirt.org > Sent: Sunday, July 12, 2015 5:44:28 PM > Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on e= ngine? > = > = > = > ----- Original Message ----- > > From: "Ryan Groten" > > To: users(a)ovirt.org > > Sent: Friday, July 10, 2015 10:45:11 PM > > Subject: [ovirt-users] Concerns with increasing vdsTimeout value on eng= ine? > > = > > = > > = > > When I try to attach new direct lun disks, the scan takes a very long t= ime > > to > > complete because of the number of pvs presented to my hosts (there is > > already a bug on this, related to the pvcreate command taking a very lo= ng > > time - https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) > > = > > = > > = > > I discovered a workaround by setting the vdsTimeout value higher (it is= 180 > > seconds by default). I changed it to 300 seconds and now the direct lun > > scan > > returns properly, but I=E2=80=99m hoping someone can warn me if this wo= rkaround is > > safe or if it=E2=80=99ll cause other potential issues? I made this chan= ge yesterday > > and so far so good. > > = > = > Hi, no serious issue can be caused by that. > Keep in mind though that any other operation will have that amount of tim= e to > complete before failing on timeout - which will > cause delays before failing (as the timeout was increased for all executi= ons) > when not everything is operational and up as expected (as in most of the > time). > I'd guess that a RFE could be opened to allow increasing the timeout of > specific operations if a user want to do that. > = > thanks, > Liron. > > = if you have HA vms and use power management (fencing), this might cause longer downtime for HA vms if host has network timeouts: the engine will wait for 3 network failures before trying to fence the host, so in case of timeouts, and increasing it to 5mins, = you should expect 15mins before engine will decide host is non-responsive a= nd fence, so if you have HA vm on this host, this will be the vm downtime as well, as the engine will restart HA vms only after fencing. you can read more on http://www.ovirt.org/Automatic_Fencing > > = > > Thanks, > > = > > Ryan > > = > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >=20 --===============0364752813843565175==-- From shtripat at redhat.com Sun Jul 12 23:57:38 2015 Content-Type: multipart/mixed; boundary="===============4129707844075975951==" MIME-Version: 1.0 From: Shubhendu Tripathi To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Mon, 13 Jul 2015 09:27:33 +0530 Message-ID: <55A3372D.5060603@redhat.com> In-Reply-To: 1152273860.36671251.1436718221377.JavaMail.zimbra@redhat.com --===============4129707844075975951== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/12/2015 09:53 PM, Omer Frenkel wrote: > > ----- Original Message ----- >> From: "Liron Aravot" >> To: "Ryan Groten" >> Cc: users(a)ovirt.org >> Sent: Sunday, July 12, 2015 5:44:28 PM >> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on = engine? >> >> >> >> ----- Original Message ----- >>> From: "Ryan Groten" >>> To: users(a)ovirt.org >>> Sent: Friday, July 10, 2015 10:45:11 PM >>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value on eng= ine? >>> >>> >>> >>> When I try to attach new direct lun disks, the scan takes a very long t= ime >>> to >>> complete because of the number of pvs presented to my hosts (there is >>> already a bug on this, related to the pvcreate command taking a very lo= ng >>> time - https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>> >>> >>> >>> I discovered a workaround by setting the vdsTimeout value higher (it is= 180 >>> seconds by default). I changed it to 300 seconds and now the direct lun >>> scan >>> returns properly, but I=E2=80=99m hoping someone can warn me if this wo= rkaround is >>> safe or if it=E2=80=99ll cause other potential issues? I made this chan= ge yesterday >>> and so far so good. >>> >> Hi, no serious issue can be caused by that. >> Keep in mind though that any other operation will have that amount of ti= me to >> complete before failing on timeout - which will >> cause delays before failing (as the timeout was increased for all execut= ions) >> when not everything is operational and up as expected (as in most of the >> time). >> I'd guess that a RFE could be opened to allow increasing the timeout of >> specific operations if a user want to do that. >> >> thanks, >> Liron. > if you have HA vms and use power management (fencing), > this might cause longer downtime for HA vms if host has network timeouts: > the engine will wait for 3 network failures before trying to fence the ho= st, > so in case of timeouts, and increasing it to 5mins, > you should expect 15mins before engine will decide host is non-responsive= and fence, > so if you have HA vm on this host, this will be the vm downtime as well, > as the engine will restart HA vms only after fencing. > > you can read more on > http://www.ovirt.org/Automatic_Fencing Even I am in a need where, I try to delete all the 256 gluster volume = snapshots using a single gluster CLI command, and engine gets timed out. So, as Liron suggested it would be better if at VDSM verb level we are = able to set timeout. That would be better option and caller needs to use = the feature judicially :) > >>> Thanks, >>> >>> Ryan >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============4129707844075975951==-- From piotr.kliczewski at gmail.com Mon Jul 13 04:12:49 2015 Content-Type: multipart/mixed; boundary="===============3632846135407205565==" MIME-Version: 1.0 From: Piotr Kliczewski To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Mon, 13 Jul 2015 10:12:47 +0200 Message-ID: In-Reply-To: 55A3372D.5060603@redhat.com --===============3632846135407205565== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2015 at 5:57 AM, Shubhendu Tripathi = wrote: > On 07/12/2015 09:53 PM, Omer Frenkel wrote: >> >> >> ----- Original Message ----- >>> >>> From: "Liron Aravot" >>> To: "Ryan Groten" >>> Cc: users(a)ovirt.org >>> Sent: Sunday, July 12, 2015 5:44:28 PM >>> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on >>> engine? >>> >>> >>> >>> ----- Original Message ----- >>>> >>>> From: "Ryan Groten" >>>> To: users(a)ovirt.org >>>> Sent: Friday, July 10, 2015 10:45:11 PM >>>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value on >>>> engine? >>>> >>>> >>>> >>>> When I try to attach new direct lun disks, the scan takes a very long >>>> time >>>> to >>>> complete because of the number of pvs presented to my hosts (there is >>>> already a bug on this, related to the pvcreate command taking a very >>>> long >>>> time - https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>>> >>>> >>>> >>>> I discovered a workaround by setting the vdsTimeout value higher (it is >>>> 180 >>>> seconds by default). I changed it to 300 seconds and now the direct lun >>>> scan >>>> returns properly, but I=E2=80=99m hoping someone can warn me if this w= orkaround >>>> is >>>> safe or if it=E2=80=99ll cause other potential issues? I made this cha= nge >>>> yesterday >>>> and so far so good. >>>> >>> Hi, no serious issue can be caused by that. >>> Keep in mind though that any other operation will have that amount of >>> time to >>> complete before failing on timeout - which will >>> cause delays before failing (as the timeout was increased for all >>> executions) >>> when not everything is operational and up as expected (as in most of the >>> time). >>> I'd guess that a RFE could be opened to allow increasing the timeout of >>> specific operations if a user want to do that. >>> >>> thanks, >>> Liron. >> >> if you have HA vms and use power management (fencing), >> this might cause longer downtime for HA vms if host has network timeouts: >> the engine will wait for 3 network failures before trying to fence the >> host, >> so in case of timeouts, and increasing it to 5mins, >> you should expect 15mins before engine will decide host is non-responsive >> and fence, >> so if you have HA vm on this host, this will be the vm downtime as well, >> as the engine will restart HA vms only after fencing. >> >> you can read more on >> http://www.ovirt.org/Automatic_Fencing > > > Even I am in a need where, I try to delete all the 256 gluster volume > snapshots using a single gluster CLI command, and engine gets timed out. > So, as Liron suggested it would be better if at VDSM verb level we are ab= le > to set timeout. That would be better option and caller needs to use the > feature judicially :) > Please open a RFE for being able to set operation timeout for single command call with description of use cases for which you would like to set the timeout. > >> >>>> Thanks, >>>> >>>> Ryan >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --===============3632846135407205565==-- From shtripat at redhat.com Mon Jul 13 04:25:20 2015 Content-Type: multipart/mixed; boundary="===============4760478764569549705==" MIME-Version: 1.0 From: Shubhendu Tripathi To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Mon, 13 Jul 2015 13:55:15 +0530 Message-ID: <55A375EB.8020704@redhat.com> In-Reply-To: CAKU0_r=MhaB-jtcn2QgS_71Fs-c-zJi8_0i3geWyLmH3tBbjYA@mail.gmail.com --===============4760478764569549705== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/13/2015 01:42 PM, Piotr Kliczewski wrote: > On Mon, Jul 13, 2015 at 5:57 AM, Shubhendu Tripathi wrote: >> On 07/12/2015 09:53 PM, Omer Frenkel wrote: >>> >>> ----- Original Message ----- >>>> From: "Liron Aravot" >>>> To: "Ryan Groten" >>>> Cc: users(a)ovirt.org >>>> Sent: Sunday, July 12, 2015 5:44:28 PM >>>> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on >>>> engine? >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Ryan Groten" >>>>> To: users(a)ovirt.org >>>>> Sent: Friday, July 10, 2015 10:45:11 PM >>>>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value on >>>>> engine? >>>>> >>>>> >>>>> >>>>> When I try to attach new direct lun disks, the scan takes a very long >>>>> time >>>>> to >>>>> complete because of the number of pvs presented to my hosts (there is >>>>> already a bug on this, related to the pvcreate command taking a very >>>>> long >>>>> time - https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>>>> >>>>> >>>>> >>>>> I discovered a workaround by setting the vdsTimeout value higher (it = is >>>>> 180 >>>>> seconds by default). I changed it to 300 seconds and now the direct l= un >>>>> scan >>>>> returns properly, but I=E2=80=99m hoping someone can warn me if this = workaround >>>>> is >>>>> safe or if it=E2=80=99ll cause other potential issues? I made this ch= ange >>>>> yesterday >>>>> and so far so good. >>>>> >>>> Hi, no serious issue can be caused by that. >>>> Keep in mind though that any other operation will have that amount of >>>> time to >>>> complete before failing on timeout - which will >>>> cause delays before failing (as the timeout was increased for all >>>> executions) >>>> when not everything is operational and up as expected (as in most of t= he >>>> time). >>>> I'd guess that a RFE could be opened to allow increasing the timeout of >>>> specific operations if a user want to do that. >>>> >>>> thanks, >>>> Liron. >>> if you have HA vms and use power management (fencing), >>> this might cause longer downtime for HA vms if host has network timeout= s: >>> the engine will wait for 3 network failures before trying to fence the >>> host, >>> so in case of timeouts, and increasing it to 5mins, >>> you should expect 15mins before engine will decide host is non-responsi= ve >>> and fence, >>> so if you have HA vm on this host, this will be the vm downtime as well, >>> as the engine will restart HA vms only after fencing. >>> >>> you can read more on >>> http://www.ovirt.org/Automatic_Fencing >> >> Even I am in a need where, I try to delete all the 256 gluster volume >> snapshots using a single gluster CLI command, and engine gets timed out. >> So, as Liron suggested it would be better if at VDSM verb level we are a= ble >> to set timeout. That would be better option and caller needs to use the >> feature judicially :) >> > Please open a RFE for being able to set operation timeout for single > command call with description of use cases for which > you would like to set the timeout. Piotr, I created an RFE BZ at https://bugzilla.redhat.com/show_bug.cgi?id=3D124237= 3. Thanks and Regards, Shubhendu >>>>> Thanks, >>>>> >>>>> Ryan >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > --===============4760478764569549705==-- From Ryan.Groten at stantec.com Mon Jul 13 11:12:30 2015 Content-Type: multipart/mixed; boundary="===============7255761732556717925==" MIME-Version: 1.0 From: Groten, Ryan To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Mon, 13 Jul 2015 15:12:27 +0000 Message-ID: <3ee462398e0b4e8fa3480fc7cd57c39e@CD1911-M21.corp.ads> In-Reply-To: 55A375EB.8020704@redhat.com --===============7255761732556717925== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thanks for the responses everyone and for the RFE. I do use HA in some pla= ces at the moment, but I do see another timeout value called vdsConnectionT= imeout. Would HA use this value or vdsTimeout (set to 2 by default) when a= ttempting to contact the host? -----Original Message----- From: Shubhendu Tripathi [mailto:shtripat(a)redhat.com] = Sent: Monday, July 13, 2015 2:25 AM To: Piotr Kliczewski Cc: Omer Frenkel; Groten, Ryan; users(a)ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on eng= ine? On 07/13/2015 01:42 PM, Piotr Kliczewski wrote: > On Mon, Jul 13, 2015 at 5:57 AM, Shubhendu Tripathi wrote: >> On 07/12/2015 09:53 PM, Omer Frenkel wrote: >>> >>> ----- Original Message ----- >>>> From: "Liron Aravot" >>>> To: "Ryan Groten" >>>> Cc: users(a)ovirt.org >>>> Sent: Sunday, July 12, 2015 5:44:28 PM >>>> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout = >>>> value on engine? >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Ryan Groten" >>>>> To: users(a)ovirt.org >>>>> Sent: Friday, July 10, 2015 10:45:11 PM >>>>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value = >>>>> on engine? >>>>> >>>>> >>>>> >>>>> When I try to attach new direct lun disks, the scan takes a very = >>>>> long time to complete because of the number of pvs presented to my = >>>>> hosts (there is already a bug on this, related to the pvcreate = >>>>> command taking a very long time - = >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>>>> >>>>> >>>>> >>>>> I discovered a workaround by setting the vdsTimeout value higher = >>>>> (it is >>>>> 180 >>>>> seconds by default). I changed it to 300 seconds and now the = >>>>> direct lun scan returns properly, but I=E2=80=99m hoping someone can = warn = >>>>> me if this workaround is safe or if it=E2=80=99ll cause other potenti= al = >>>>> issues? I made this change yesterday and so far so good. >>>>> >>>> Hi, no serious issue can be caused by that. >>>> Keep in mind though that any other operation will have that amount = >>>> of time to complete before failing on timeout - which will cause = >>>> delays before failing (as the timeout was increased for all >>>> executions) >>>> when not everything is operational and up as expected (as in most = >>>> of the time). >>>> I'd guess that a RFE could be opened to allow increasing the = >>>> timeout of specific operations if a user want to do that. >>>> >>>> thanks, >>>> Liron. >>> if you have HA vms and use power management (fencing), this might = >>> cause longer downtime for HA vms if host has network timeouts: >>> the engine will wait for 3 network failures before trying to fence = >>> the host, so in case of timeouts, and increasing it to 5mins, you = >>> should expect 15mins before engine will decide host is = >>> non-responsive and fence, so if you have HA vm on this host, this = >>> will be the vm downtime as well, as the engine will restart HA vms = >>> only after fencing. >>> >>> you can read more on >>> http://www.ovirt.org/Automatic_Fencing >> >> Even I am in a need where, I try to delete all the 256 gluster volume = >> snapshots using a single gluster CLI command, and engine gets timed out. >> So, as Liron suggested it would be better if at VDSM verb level we = >> are able to set timeout. That would be better option and caller needs = >> to use the feature judicially :) >> > Please open a RFE for being able to set operation timeout for single = > command call with description of use cases for which you would like to = > set the timeout. Piotr, I created an RFE BZ at https://bugzilla.redhat.com/show_bug.cgi?id=3D124237= 3. Thanks and Regards, Shubhendu >>>>> Thanks, >>>>> >>>>> Ryan >>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > --===============7255761732556717925==-- From piotr.kliczewski at gmail.com Tue Jul 14 03:05:39 2015 Content-Type: multipart/mixed; boundary="===============6369637805564100775==" MIME-Version: 1.0 From: Piotr Kliczewski To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Tue, 14 Jul 2015 09:05:37 +0200 Message-ID: In-Reply-To: 3ee462398e0b4e8fa3480fc7cd57c39e@CD1911-M21.corp.ads --===============6369637805564100775== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon, Jul 13, 2015 at 5:12 PM, Groten, Ryan w= rote: > Thanks for the responses everyone and for the RFE. I do use HA in some p= laces at the moment, but I do see another timeout value called vdsConnectio= nTimeout. Would HA use this value or vdsTimeout (set to 2 by default) when= attempting to contact the host? > There is a difference between the two: vdsConnectionTimeout - is a timeout used during connecting to a remote host. By default it is 2 seconds. vdsTimeout - high level command invocation timeout used by all commands. By default it is 3 minutes. As far as I understand you are looking for a possibility to customize vdsTimeout for some of the commands. > -----Original Message----- > From: Shubhendu Tripathi [mailto:shtripat(a)redhat.com] > Sent: Monday, July 13, 2015 2:25 AM > To: Piotr Kliczewski > Cc: Omer Frenkel; Groten, Ryan; users(a)ovirt.org > Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on e= ngine? > > On 07/13/2015 01:42 PM, Piotr Kliczewski wrote: >> On Mon, Jul 13, 2015 at 5:57 AM, Shubhendu Tripathi wrote: >>> On 07/12/2015 09:53 PM, Omer Frenkel wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Liron Aravot" >>>>> To: "Ryan Groten" >>>>> Cc: users(a)ovirt.org >>>>> Sent: Sunday, July 12, 2015 5:44:28 PM >>>>> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout >>>>> value on engine? >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Ryan Groten" >>>>>> To: users(a)ovirt.org >>>>>> Sent: Friday, July 10, 2015 10:45:11 PM >>>>>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value >>>>>> on engine? >>>>>> >>>>>> >>>>>> >>>>>> When I try to attach new direct lun disks, the scan takes a very >>>>>> long time to complete because of the number of pvs presented to my >>>>>> hosts (there is already a bug on this, related to the pvcreate >>>>>> command taking a very long time - >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>>>>> >>>>>> >>>>>> >>>>>> I discovered a workaround by setting the vdsTimeout value higher >>>>>> (it is >>>>>> 180 >>>>>> seconds by default). I changed it to 300 seconds and now the >>>>>> direct lun scan returns properly, but I=E2=80=99m hoping someone can= warn >>>>>> me if this workaround is safe or if it=E2=80=99ll cause other potent= ial >>>>>> issues? I made this change yesterday and so far so good. >>>>>> >>>>> Hi, no serious issue can be caused by that. >>>>> Keep in mind though that any other operation will have that amount >>>>> of time to complete before failing on timeout - which will cause >>>>> delays before failing (as the timeout was increased for all >>>>> executions) >>>>> when not everything is operational and up as expected (as in most >>>>> of the time). >>>>> I'd guess that a RFE could be opened to allow increasing the >>>>> timeout of specific operations if a user want to do that. >>>>> >>>>> thanks, >>>>> Liron. >>>> if you have HA vms and use power management (fencing), this might >>>> cause longer downtime for HA vms if host has network timeouts: >>>> the engine will wait for 3 network failures before trying to fence >>>> the host, so in case of timeouts, and increasing it to 5mins, you >>>> should expect 15mins before engine will decide host is >>>> non-responsive and fence, so if you have HA vm on this host, this >>>> will be the vm downtime as well, as the engine will restart HA vms >>>> only after fencing. >>>> >>>> you can read more on >>>> http://www.ovirt.org/Automatic_Fencing >>> >>> Even I am in a need where, I try to delete all the 256 gluster volume >>> snapshots using a single gluster CLI command, and engine gets timed out. >>> So, as Liron suggested it would be better if at VDSM verb level we >>> are able to set timeout. That would be better option and caller needs >>> to use the feature judicially :) >>> >> Please open a RFE for being able to set operation timeout for single >> command call with description of use cases for which you would like to >> set the timeout. > > Piotr, > > I created an RFE BZ at https://bugzilla.redhat.com/show_bug.cgi?id=3D1242= 373. > > Thanks and Regards, > Shubhendu > >>>>>> Thanks, >>>>>> >>>>>> Ryan >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> > --===============6369637805564100775==-- From shtripat at redhat.com Tue Jul 14 03:09:44 2015 Content-Type: multipart/mixed; boundary="===============8614769832182003006==" MIME-Version: 1.0 From: Shubhendu Tripathi To: users at ovirt.org Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on engine? Date: Tue, 14 Jul 2015 12:39:38 +0530 Message-ID: <55A4B5B2.5050802@redhat.com> In-Reply-To: CAKU0_rkrZ-9CPhmc+mGmREmAisRqr2ehwevgis725PeaWofRag@mail.gmail.com --===============8614769832182003006== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/14/2015 12:35 PM, Piotr Kliczewski wrote: > On Mon, Jul 13, 2015 at 5:12 PM, Groten, Ryan = wrote: >> Thanks for the responses everyone and for the RFE. I do use HA in some = places at the moment, but I do see another timeout value called vdsConnecti= onTimeout. Would HA use this value or vdsTimeout (set to 2 by default) whe= n attempting to contact the host? >> > There is a difference between the two: > > vdsConnectionTimeout - is a timeout used during connecting to a remote > host. By default it is 2 seconds. > vdsTimeout - high level command invocation timeout used by all > commands. By default it is 3 minutes. > > As far as I understand you are looking for a possibility to customize > vdsTimeout for some of the commands. For me, yes, the case is to have an option to set higher value of = vdsTimeout for a specific command. > > >> -----Original Message----- >> From: Shubhendu Tripathi [mailto:shtripat(a)redhat.com] >> Sent: Monday, July 13, 2015 2:25 AM >> To: Piotr Kliczewski >> Cc: Omer Frenkel; Groten, Ryan; users(a)ovirt.org >> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout value on = engine? >> >> On 07/13/2015 01:42 PM, Piotr Kliczewski wrote: >>> On Mon, Jul 13, 2015 at 5:57 AM, Shubhendu Tripathi wrote: >>>> On 07/12/2015 09:53 PM, Omer Frenkel wrote: >>>>> ----- Original Message ----- >>>>>> From: "Liron Aravot" >>>>>> To: "Ryan Groten" >>>>>> Cc: users(a)ovirt.org >>>>>> Sent: Sunday, July 12, 2015 5:44:28 PM >>>>>> Subject: Re: [ovirt-users] Concerns with increasing vdsTimeout >>>>>> value on engine? >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Ryan Groten" >>>>>>> To: users(a)ovirt.org >>>>>>> Sent: Friday, July 10, 2015 10:45:11 PM >>>>>>> Subject: [ovirt-users] Concerns with increasing vdsTimeout value >>>>>>> on engine? >>>>>>> >>>>>>> >>>>>>> >>>>>>> When I try to attach new direct lun disks, the scan takes a very >>>>>>> long time to complete because of the number of pvs presented to my >>>>>>> hosts (there is already a bug on this, related to the pvcreate >>>>>>> command taking a very long time - >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1217401 ) >>>>>>> >>>>>>> >>>>>>> >>>>>>> I discovered a workaround by setting the vdsTimeout value higher >>>>>>> (it is >>>>>>> 180 >>>>>>> seconds by default). I changed it to 300 seconds and now the >>>>>>> direct lun scan returns properly, but I=E2=80=99m hoping someone ca= n warn >>>>>>> me if this workaround is safe or if it=E2=80=99ll cause other poten= tial >>>>>>> issues? I made this change yesterday and so far so good. >>>>>>> >>>>>> Hi, no serious issue can be caused by that. >>>>>> Keep in mind though that any other operation will have that amount >>>>>> of time to complete before failing on timeout - which will cause >>>>>> delays before failing (as the timeout was increased for all >>>>>> executions) >>>>>> when not everything is operational and up as expected (as in most >>>>>> of the time). >>>>>> I'd guess that a RFE could be opened to allow increasing the >>>>>> timeout of specific operations if a user want to do that. >>>>>> >>>>>> thanks, >>>>>> Liron. >>>>> if you have HA vms and use power management (fencing), this might >>>>> cause longer downtime for HA vms if host has network timeouts: >>>>> the engine will wait for 3 network failures before trying to fence >>>>> the host, so in case of timeouts, and increasing it to 5mins, you >>>>> should expect 15mins before engine will decide host is >>>>> non-responsive and fence, so if you have HA vm on this host, this >>>>> will be the vm downtime as well, as the engine will restart HA vms >>>>> only after fencing. >>>>> >>>>> you can read more on >>>>> http://www.ovirt.org/Automatic_Fencing >>>> Even I am in a need where, I try to delete all the 256 gluster volume >>>> snapshots using a single gluster CLI command, and engine gets timed ou= t. >>>> So, as Liron suggested it would be better if at VDSM verb level we >>>> are able to set timeout. That would be better option and caller needs >>>> to use the feature judicially :) >>>> >>> Please open a RFE for being able to set operation timeout for single >>> command call with description of use cases for which you would like to >>> set the timeout. >> Piotr, >> >> I created an RFE BZ at https://bugzilla.redhat.com/show_bug.cgi?id=3D124= 2373. >> >> Thanks and Regards, >> Shubhendu >> >>>>>>> Thanks, >>>>>>> >>>>>>> Ryan >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users(a)ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/users >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users > --===============8614769832182003006==--