February 2016 - Users - oVirt List Archives

All snapshots read only
by Colin Coe 05 Feb '16

05 Feb '16

Hi all I've just noticed that all VM snapshots on one of our prod RHEV setups have gone read-only (i.e. delete is greyed out). Has anyone else seen this? Is there an easy fix for this? We have a bunch of VVMs being snapshotted nightly with snapshots being deleted after 7 days. Thanks CC

2 6

Re: [ovirt-users] Disabling migration when there is a problem with storage
by Mark Steele 05 Feb '16

05 Feb '16

I found that setting the cluster's 'Resilience Policy' to 'Do Not Migrate Virtual Machines' seems to have the desired effect while still letting me manually and via 'Maintenance' migrate VM's Thanks all *** *Mark Steele* CIO / VP Technical Operations | TelVue Corporation TelVue - We Share Your Vision 800.885.8886 x128 | msteele(a)telvue.com | http://www.telvue.com twitter: http://twitter.com/telvue | facebook: https://www.facebook.com/telvue

1 0

Re: [ovirt-users] Several VM's stuck in Migration
by Mark Steele 05 Feb '16

05 Feb '16

I was able to clear the stuck items by restarting the Host. *** *Mark Steele* CIO / VP Technical Operations | TelVue Corporation TelVue - We Share Your Vision 800.885.8886 x128 | msteele(a)telvue.com | http://www.telvue.com twitter: http://twitter.com/telvue | facebook: https://www.facebook.com/telvue

1 0

Re: [ovirt-users] Host maintenance - VM migration logic
by Patrick Russell 04 Feb '16

04 Feb '16

--_000_C7A71BBF1BB3465082D3AB68025787A6volusioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gY2FzZSBhbnlvbmUgZWxzZSBydW5zIGludG8gdGhpcywgb25lIG9mIG91ciBhZG1pbnMgaGFk IGNoYW5nZWQgdGhlIGNsdXN0ZXIgdG8gcG9saWN5IHRvIG9wdGltaXplIGZvciBzcGVlZCByYXRo ZXIgdGhhbiB1dGlsaXphdGlvbi4gUmVjb25maWd1cmluZyB0aGlzIG9wdGlvbiByZXNvbHZlZCB0 aGUgaXNzdWUgYW5kIHRoZSBtaWdyYXRpb25zIGFyZSBubyBsb25nZXIgb3ZlcmxvYWRpbmcgYSBz aW5nbGUgaG9zdC4NCg0KLVBhdHJpY2sNCg0KRnJvbTogPHVzZXJzLWJvdW5jZXNAb3ZpcnQub3Jn PG1haWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZz4+IG9uIGJlaGFsZiBvZiBQYXRyaWNrIFJ1 c3NlbGwgPHBhdHJpY2tfcnVzc2VsbEB2b2x1c2lvbi5jb208bWFpbHRvOnBhdHJpY2tfcnVzc2Vs bEB2b2x1c2lvbi5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgYXQgMTA6 MTEgQU0NClRvOiAidXNlcnNAb3ZpcnQub3JnPG1haWx0bzp1c2Vyc0BvdmlydC5vcmc+IiA8dXNl cnNAb3ZpcnQub3JnPG1haWx0bzp1c2Vyc0BvdmlydC5vcmc+Pg0KU3ViamVjdDogW292aXJ0LXVz ZXJzXSBIb3N0IG1haW50ZW5hbmNlIC0gVk0gbWlncmF0aW9uIGxvZ2ljDQoNCklzIHRoZXJlIGFu eSB3YXkgbWlncmF0ZSBWTeKAmXMgbW9yZSBldmVubHkgYWNyb3NzIHRoZSBjbHVzdGVyIHdoZW4g YSBob3N0IGlzIGJlaW5nIHBsYWNlZCBpbnRvIG1haW50ZW5hbmNlPyBDdXJyZW50bHkgaXQgYXR0 ZW1wdHMgdG8gYXV0byBtaWdyYXRlIGFsbCB0aGUgVk3igJlzIHRvIGFub3RoZXIgc2luZ2xlIGhv c3QgYW5kIHRoZW4gYmFsYW5jZSBvdXQuIFdoZW4gdGhlIGRlc3RpbmF0aW9uIGhvc3QgaXMgbW9y ZSB0aGFuIDUwJSBtZW1vcnkgdXRpbGl6ZWQgdGhpcyBoYXMgY2F1c2VkIG92ZXIgc3Vic2NyaXB0 aW9uIHByb2JsZW1zLiBTb21lIG9mIG91ciBtb3JlIGhlYXZpbHkgdXNlZCBob3N0cyBlbmRpbmcg dXAgdXNpbmcgYWxsIHRoZSBtZW1vcnkgYW5kIHN0b3AgY29tbXVuaWNhdGluZyB3aXRoIGVuZ2lu ZS4gSWYgaXTigJlzIG5vdCBwb3NzaWJsZSwgaG93IGFyZSBvdGhlciB0ZWFtcyBoYW5kbGluZyB0 aGlzPyBNYW51YWwgbWlncmF0aW9ucyBiZWZvcmUgbWFpbnRlbmFuY2UgbW9kZT8NCg0KVGhhbmtz LA0KUGF0cmljaw0KDQo= --_000_C7A71BBF1BB3465082D3AB68025787A6volusioncom_ Content-Type: text/html; charset="utf-8" Content-ID: <CEF0E52E23235448A619DAA7C3E109A6(a)namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQ291cmllciwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkluIGNhc2UgYW55b25lIGVsc2UgcnVucyBpbnRvIHRoaXMsIG9uZSBvZiBvdXIgYWRtaW5z IGhhZCBjaGFuZ2VkIHRoZSBjbHVzdGVyIHRvIHBvbGljeSB0byBvcHRpbWl6ZSBmb3Igc3BlZWQg cmF0aGVyIHRoYW4gdXRpbGl6YXRpb24uIFJlY29uZmlndXJpbmcgdGhpcyBvcHRpb24gcmVzb2x2 ZWQgdGhlIGlzc3VlIGFuZCB0aGUgbWlncmF0aW9ucyBhcmUgbm8gbG9uZ2VyIG92ZXJsb2FkaW5n IGEgc2luZ2xlIGhvc3QuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tUGF0cmljazwv ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZsdDs8YSBocmVm PSJtYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmciPnVzZXJzLWJvdW5jZXNAb3ZpcnQub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIFBhdHJpY2sgUnVzc2VsbCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBhdHJpY2tfcnVzc2VsbEB2b2x1c2lvbi5jb20iPnBhdHJpY2tfcnVzc2VsbEB2b2x1c2lvbi5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw YW4+VGh1cnNkYXksIEZlYnJ1YXJ5IDQsIDIwMTYgYXQgMTA6MTEgQU08YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86dXNl cnNAb3ZpcnQub3JnIj51c2Vyc0BvdmlydC5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86dXNlcnNAb3ZpcnQub3JnIj51c2Vyc0BvdmlydC5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W292aXJ0LXVzZXJzXSBIb3N0 IG1haW50ZW5hbmNlIC0gVk0gbWlncmF0aW9uIGxvZ2ljPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb3Vy aWVyLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PklzIHRoZXJlIGFueSB3YXkgbWlncmF0ZSBWTeKAmXMg bW9yZSBldmVubHkgYWNyb3NzIHRoZSBjbHVzdGVyIHdoZW4gYSBob3N0IGlzIGJlaW5nIHBsYWNl ZCBpbnRvIG1haW50ZW5hbmNlPyBDdXJyZW50bHkgaXQgYXR0ZW1wdHMgdG8gYXV0byBtaWdyYXRl IGFsbCB0aGUgVk3igJlzIHRvIGFub3RoZXIgc2luZ2xlIGhvc3QgYW5kIHRoZW4gYmFsYW5jZSBv dXQuIFdoZW4gdGhlIGRlc3RpbmF0aW9uIGhvc3QgaXMgbW9yZSB0aGFuIDUwJSBtZW1vcnkNCiB1 dGlsaXplZCB0aGlzIGhhcyBjYXVzZWQgb3ZlciBzdWJzY3JpcHRpb24gcHJvYmxlbXMuIFNvbWUg b2Ygb3VyIG1vcmUgaGVhdmlseSB1c2VkIGhvc3RzIGVuZGluZyB1cCB1c2luZyBhbGwgdGhlIG1l bW9yeSBhbmQgc3RvcCBjb21tdW5pY2F0aW5nIHdpdGggZW5naW5lLiBJZiBpdOKAmXMgbm90IHBv c3NpYmxlLCBob3cgYXJlIG90aGVyIHRlYW1zIGhhbmRsaW5nIHRoaXM/IE1hbnVhbCBtaWdyYXRp b25zIGJlZm9yZSBtYWludGVuYW5jZSBtb2RlPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5QYXRyaWNrPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C7A71BBF1BB3465082D3AB68025787A6volusioncom_--

1 0

Re: [ovirt-users] R: Re: Network instability after upgrade 3.6.0 -> 3.6.1
by Jon Archer 04 Feb '16

04 Feb '16

This is a multi-part message in MIME format. --------------060204050902010701050107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stefano, It's definitely not the switch, it seems to be the latest kernel package (kernel-3.10.0-327.3.1.el7.x86_64) which stops bonding working correctly, reverting back to the previous kernel brings the network up in 802.3ad mode (4). I know, from reading the release notes of 7.2, that there were some changes to the bonding bits in the kernel so i'm guessing maybe some defaults have changed. I'll keep digging and post back as soon as i have something. Jon On 29/12/15 19:55, Stefano Danzi wrote: > Hi! I didn't solve yet. I'm still using mode 2 on bond interface. > What's your switch model and firmware version? > > -------- Messaggio originale -------- > Da: Jon Archer <jon(a)rosslug.org.uk> > Data: 29/12/2015 19:26 (GMT+01:00) > A: users(a)ovirt.org > Oggetto: Re: [ovirt-users] Network instability after upgrade 3.6.0 -> > 3.6.1 > > Stefano, > > I am currently experiencing the same issue. 2x nic lacp config at > switch, mode 4 bond at server with no connectivity. Interestingly I am > able to ping the switch itself. > > I haven't had time to investigate thoroughly but my first thought is > an update somewhere. > > Did you ever resolve and get back to mode=4? > > Jon > > On 17 December 2015 17:51:50 GMT+00:00, Stefano Danzi > <s.danzi(a)hawai.it> wrote: > > I partially solve the problem. > > My host machine has 2 network interfaces with a bond. The bond was > configured with mode=4 (802.3ad) and switch was configured in the same way. > If I remove one network cable the network become stable. With both > cables attached the network is instable. > > I removed the link aggregation configuration from switch and change the > bond in mode=2 (balance-xor). Now the network are stable. > The strange thing is that previous configuration worked fine for one > year... since the last upgrade. > > Now ha-agent don't reboot the hosted-engine anymore, but I receive two > emails from brocker evere 2/5 minutes. > First a mail with "ovirt-hosted-engine state transition > StartState-ReinitializeFSM" and after "ovirt-hosted-engine state > transition ReinitializeFSM-EngineStarting" > > > Il 17/12/2015 10.51, Stefano Danzi ha scritto: > > Hello, I have one testing host (only one host) with self > hosted engine and 2 VM (one linux and one windows). After > upgrade ovirt from 3.6.0 to 3.6.1 the network connection works > discontinuously. Every 10 minutes HA agent restart hosted > engine VM because result down. But the machine is UP, only the > network stop to work for some minutes. I activate global > maintenace mode to prevent engine reboot. If I ssh to the > hosted engine sometimes the connection work and sometimes no. > Using VNC connection to engine I see that sometime VM reach > external network and sometimes no. If I do a tcpdump on > phisical ethernet interface I don't see any packet when > network on vm don't work. Same thing happens fo others two VM. > Before the upgrade I never had network problems. > ------------------------------------------------------------------------ > 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 > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. --------------060204050902010701050107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Stefano, It's definitely not the switch, it seems to be the latest kernel package (kernel-3.10.0-327.3.1.el7.x86_64) which stops bonding working correctly, reverting back to the previous kernel brings the network up in 802.3ad mode (4). I know, from reading the release notes of 7.2, that there were some changes to the bonding bits in the kernel so i'm guessing maybe some defaults have changed. I'll keep digging and post back as soon as i have something. Jon <div class="moz-cite-prefix">On 29/12/15 19:55, Stefano Danzi wrote: </div> <blockquote cite="mid:yuu6vcix8xss464s04yxu6xv.1451418904304@email.android.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Hi! I didn't solve yet. I'm still using mode 2 on bond interface. What's your switch model and firmware version? -------- Messaggio originale -------- Da: Jon Archer <a class="moz-txt-link-rfc2396E" href="mailto:jon@rosslug.org.uk"><jon(a)rosslug.org.uk></a> Data: 29/12/2015 19:26 (GMT+01:00) A: <a class="moz-txt-link-abbreviated" href="mailto:users@ovirt.org">users(a)ovirt.org</a> Oggetto: Re: [ovirt-users] Network instability after upgrade 3.6.0 -> 3.6.1 Stefano, I am currently experiencing the same issue. 2x nic lacp config at switch, mode 4 bond at server with no connectivity. Interestingly I am able to ping the switch itself. I haven't had time to investigate thoroughly but my first thought is an update somewhere. Did you ever resolve and get back to mode=4? Jon <div class="gmail_quote">On 17 December 2015 17:51:50 GMT+00:00, Stefano Danzi <a class="moz-txt-link-rfc2396E" href="mailto:s.danzi@hawai.it"><s.danzi(a)hawai.it></a> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre class="k9mail">I partially solve the problem. My host machine has 2 network interfaces with a bond. The bond was configured with mode=4 (802.3ad) and switch was configured in the same way. If I remove one network cable the network become stable. With both cables attached the network is instable. I removed the link aggregation configuration from switch and change the bond in mode=2 (balance-xor). Now the network are stable. The strange thing is that previous configuration worked fine for one year... since the last upgrade. Now ha-agent don't reboot the hosted-engine anymore, but I receive two emails from brocker evere 2/5 minutes. First a mail with "ovirt-hosted-engine state transition StartState-ReinitializeFSM" and after "ovirt-hosted-engine state transition ReinitializeFSM-EngineStarting" Il 17/12/2015 10.51, Stefano Danzi ha scritto: <blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hello, I have one testing host (only one host) with self hosted engine and 2 VM (one linux and one windows). After upgrade ovirt from 3.6.0 to 3.6.1 the network connection works discontinuously. Every 10 minutes HA agent restart hosted engine VM because result down. But the machine is UP, only the network stop to work for some minutes. I activate global maintenace mode to prevent engine reboot. If I ssh to the hosted engine sometimes the connection work and sometimes no. Using VNC connection to engine I see that sometime VM reach external network and sometimes no. If I do a tcpdump on phisical ethernet interface I don't see any packet when network on vm don't work. Same thing happens fo others two VM. Before the upgrade I never had network problems. <hr> Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users(a)ovirt.org</a> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a></blockquote> <hr> Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users(a)ovirt.org</a> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre></blockquote></div> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. </blockquote> </body></html> --------------060204050902010701050107--

5 14

API: detailed quota information, where's it at?
by Tim Bielawa 04 Feb '16

04 Feb '16

I've been able to run the simple commands to enumerate quotas in a datacenter, and to select a quota by name. What I can not figure out how to do is how to receive detailed information about a quota from the API. Here's how I queried the basic information (using the python ovirtsdk module): import ovirtsdk.api > api = ovirtsdk.api.API(url=url, username=name, password=password, ...) > datacenter = api.datacenters.get(name="my-data-center") > team_quota = datacenter.quotas.get(name="my-teams-quota") Which works well enough, but doesn't really provide any actual *valuable* information (just the name, id, description, that kind of stuff). So where is the useful stuff hidden? The stuff of real value? I have not found any useful resources while scouring the Internet for this answer. I want to be able to hit this API and ask for detailed information about the usage of a quota: How much capacity is my team allotted on a given storage domain? How much capacity are we presently consuming? Likewise with CPU/Memory allocation type quotas. Is this possible, or a pipe dream? Environment: RHEVM Version: 3.5.6.0-1 Python SDK Version: 3.5.6.0-1 Thanks again folks! -- Tim Bielawa, Sr. ${::title} Cell: 919.332.6411 | IRC: tbielawa (#platops) 1BA0 4FAB 4C13 FBA0 A036 4958 AD05 E75E 0333 AE37

1 1

Re: [ovirt-users] Mixing CPU types
by Matthew Trent 04 Feb '16

04 Feb '16

Though our new oVirt setup is better in most ways, cross-CPU-type migration is one of the features I miss from Proxmox. KVM supports mixed-CPU migration for a while now, even between AMD and Intel. http://www.linux-kvm.org/page/Migration I'm using a bunch of re-purposed servers with a mix of AMD and Intel. I separate them into clusters, as noted, but it sure would be nice to be able to live migrate between them. :) -- Matthew Trent Network Engineer Lewis County IT Services > Hi Rene, > > Thank you very much for coming back to me. > > That's perfect then and answers my questions exactly. > > Much appreciated. > > Regards. > >Neil Wilson. > > >On Wed, Jan 27, 2016 at 1:57 PM, René Koch <rkoch at rk-it.at> wrote: >> >> Hi Neil, >> >> You can mix cpu types (but not AMD and Intel) if you leave the cluster >> level at the lowest cpu level. >> I personally don't mix cpu levels if possible, but instead create own >> clusters for each cpu type in order to be able to use the newest cpu >> features... >> >> >> Regards, >> René >> >> >> On 01/27/2016 12:53 PM, Neil wrote: >> >> Hi guys, >> >> I currently have an oVirt 3.5 cluster with Sandy Bridge Xeon CPU's, and I >> need to add a new host for more RAM and vCPU's, however the new Xeon e5 >> cpu's are Haswell based. >> >> Can I mix CPU types (Haswell and Sandy Bridge) in my cluster and will I be >> able to migrate between my hosts? >> >> I'm guessing that for this to work I'll need to leave my "CPU type" set to >> Sandy Bridge, will the Haswell based CPU be compatible with my cluster, but >> just run without any Haswell type features? >> >> Apologies if this is a dumb question or if it's been answered before. >> >> Thank you. >> >> Regards. >> >> Neil Wilson >>

3 4

Host maintenance - VM migration logic
by Patrick Russell 04 Feb '16

04 Feb '16

--_000_307CC58F72BE4EFE86FF1F66B2921786volusioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlcmUgYW55IHdheSBtaWdyYXRlIFZN4oCZcyBtb3JlIGV2ZW5seSBhY3Jvc3MgdGhlIGNs dXN0ZXIgd2hlbiBhIGhvc3QgaXMgYmVpbmcgcGxhY2VkIGludG8gbWFpbnRlbmFuY2U/IEN1cnJl bnRseSBpdCBhdHRlbXB0cyB0byBhdXRvIG1pZ3JhdGUgYWxsIHRoZSBWTeKAmXMgdG8gYW5vdGhl ciBzaW5nbGUgaG9zdCBhbmQgdGhlbiBiYWxhbmNlIG91dC4gV2hlbiB0aGUgZGVzdGluYXRpb24g aG9zdCBpcyBtb3JlIHRoYW4gNTAlIG1lbW9yeSB1dGlsaXplZCB0aGlzIGhhcyBjYXVzZWQgb3Zl ciBzdWJzY3JpcHRpb24gcHJvYmxlbXMuIFNvbWUgb2Ygb3VyIG1vcmUgaGVhdmlseSB1c2VkIGhv c3RzIGVuZGluZyB1cCB1c2luZyBhbGwgdGhlIG1lbW9yeSBhbmQgc3RvcCBjb21tdW5pY2F0aW5n IHdpdGggZW5naW5lLiBJZiBpdOKAmXMgbm90IHBvc3NpYmxlLCBob3cgYXJlIG90aGVyIHRlYW1z IGhhbmRsaW5nIHRoaXM/IE1hbnVhbCBtaWdyYXRpb25zIGJlZm9yZSBtYWludGVuYW5jZSBtb2Rl Pw0KDQpUaGFua3MsDQpQYXRyaWNrDQoNCg== --_000_307CC58F72BE4EFE86FF1F66B2921786volusioncom_ Content-Type: text/html; charset="utf-8" Content-ID: <A937B8403AB28744B75ACA15F4F1362F(a)namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQ291cmllciwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JcyB0aGVyZSBh bnkgd2F5IG1pZ3JhdGUgVk3igJlzIG1vcmUgZXZlbmx5IGFjcm9zcyB0aGUgY2x1c3RlciB3aGVu IGEgaG9zdCBpcyBiZWluZyBwbGFjZWQgaW50byBtYWludGVuYW5jZT8gQ3VycmVudGx5IGl0IGF0 dGVtcHRzIHRvIGF1dG8gbWlncmF0ZSBhbGwgdGhlIFZN4oCZcyB0byBhbm90aGVyIHNpbmdsZSBo b3N0IGFuZCB0aGVuIGJhbGFuY2Ugb3V0LiBXaGVuIHRoZSBkZXN0aW5hdGlvbiBob3N0IGlzIG1v cmUgdGhhbiA1MCUgbWVtb3J5DQogdXRpbGl6ZWQgdGhpcyBoYXMgY2F1c2VkIG92ZXIgc3Vic2Ny aXB0aW9uIHByb2JsZW1zLiBTb21lIG9mIG91ciBtb3JlIGhlYXZpbHkgdXNlZCBob3N0cyBlbmRp bmcgdXAgdXNpbmcgYWxsIHRoZSBtZW1vcnkgYW5kIHN0b3AgY29tbXVuaWNhdGluZyB3aXRoIGVu Z2luZS4gSWYgaXTigJlzIG5vdCBwb3NzaWJsZSwgaG93IGFyZSBvdGhlciB0ZWFtcyBoYW5kbGlu ZyB0aGlzPyBNYW51YWwgbWlncmF0aW9ucyBiZWZvcmUgbWFpbnRlbmFuY2UgbW9kZT88L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+UGF0cmljazwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRV UkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_307CC58F72BE4EFE86FF1F66B2921786volusioncom_--

1 0

How does VDSM-Fake actually work?
by Nicolás 04 Feb '16

04 Feb '16

This is a multi-part message in MIME format. --------------050502090505080806060902 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I'm trying to set up VDSM-Fake (git://gerrit.ovirt.org/ovirt-vdsmfake.git) for some tests, however, I'm a bit confused about how does it actually work. As the instructions say, I was able to build the project with Maven (however, the org.ovirt.vdsm-jsonrpc-java dependency version had to be changed to 1.1.5 instead of 1.1.2-SNAPSHOT in pom.xml as this latter is no longer provided at the repository). Once built, I run mvn jetty:run and the server started correctly: 2016-02-02 11:01:51.957:INFO::jetty-6.1.26 2016-02-02 11:01:52.804:INFO::No Transaction manager found - if your webapp requires one, please configure one. 2016-02-02 11:01:53,424 Application initialized. 2016-02-02 11:01:53,442 Opening a Stomp server localhost:54322 2016-02-02 11:01:53.702:INFO::Started SelectChannelConnector@0.0.0.0:54321 [INFO] Started Jetty Server [INFO] Starting scanner at interval of 10 seconds. I could indeed verify it's listening on the VDSM port: [root@host ovirt-vdsmfake]# netstat -atpn | grep 54321 tcp6 0 0 :::54321 :::* LISTEN 44870/java So the next step is to add a fake host via REST. I used scripts provided here <http://www.ovirt.org/REST_API_Using_BASH_Automation> and I successfully added the host, however, it starts installing all the VDSM packages as it were a normal host and therefore it tries to start vdsmd as well, which throws an error as the Jetty Server is already listening on the 54321 port. I shut down the Jetty Server and allowed oVirt Manager to install all the packages properly, then stopped vdsmd and started the Jetty Server, but expectedly oVirt Engine fails with message "Host xxx is non responsive", so what I actually got is a real VDSM host and not a fake one. FWIW, the fake VDSM runs on a different host, ports are reacheable from the oVirt engine, proper /etc/hosts has been added to the engine to reach the host, and no further customization of web.xml has been done. I feel like I'm missing something here. Could someone shed some light on what's wrong? Thanks. Nicolás --------------050502090505080806060902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, I'm trying to set up VDSM-Fake (git://gerrit.ovirt.org/ovirt-vdsmfake.git) for some tests, however, I'm a bit confused about how does it actually work. As the instructions say, I was able to build the project with Maven (however, the org.ovirt.vdsm-jsonrpc-java dependency version had to be changed to 1.1.5 instead of 1.1.2-SNAPSHOT in pom.xml as this latter is no longer provided at the repository). Once built, I run mvn jetty:run and the server started correctly: <blockquote>2016-02-02 11:01:51.957:<a class="moz-txt-link-freetext" href="INFO::jetty-6.1.26">INFO::jetty-6.1.26</a> 2016-02-02 11:01:52.804:<a class="moz-txt-link-freetext" href="INFO::No">INFO::No</a> Transaction manager found - if your webapp requires one, please configure one. 2016-02-02 11:01:53,424 Application initialized. 2016-02-02 11:01:53,442 Opening a Stomp server localhost:54322 2016-02-02 11:01:53.702:<a class="moz-txt-link-freetext" href="INFO::Started">INFO::Started</a> <a class="moz-txt-link-abbreviated" href="mailto:SelectChannelConnector@0.0.0.0:54321">SelectChannelConnector@0.0.0.0:54321</a> [INFO] Started Jetty Server [INFO] Starting scanner at interval of 10 seconds. </blockquote> I could indeed verify it's listening on the VDSM port: <blockquote>[root@host ovirt-vdsmfake]# netstat -atpn | grep 54321 tcp6 0 0 :::54321 :::* LISTEN 44870/java </blockquote> So the next step is to add a fake host via REST. I used scripts provided <a href="http://www.ovirt.org/REST_API_Using_BASH_Automation">here</a> and I successfully added the host, however, it starts installing all the VDSM packages as it were a normal host and therefore it tries to start vdsmd as well, which throws an error as the Jetty Server is already listening on the 54321 port. I shut down the Jetty Server and allowed oVirt Manager to install all the packages properly, then stopped vdsmd and started the Jetty Server, but expectedly oVirt Engine fails with message "Host xxx is non responsive", so what I actually got is a real VDSM host and not a fake one. FWIW, the fake VDSM runs on a different host, ports are reacheable from the oVirt engine, proper /etc/hosts has been added to the engine to reach the host, and no further customization of web.xml has been done. I feel like I'm missing something here. Could someone shed some light on what's wrong? Thanks. Nicolás </body> </html> --------------050502090505080806060902--

3 2

howto change hosted-engine config memory
by Paul Groeneweg | Pazion 04 Feb '16

04 Feb '16

I am trying to change memory of my hosted engine. I am running oVirt 3.6 with CentOS 6 Hosts with hosted engine on nfs3 1. I put hosted-engine to maintenance, shutdown vm 2. update /etc/ovirt-hosted-engine/vm.conf 3. restart vm disable maintenance Memory is still old value. How can I change the hosted engine VM? I did found: http://www.ovirt.org/Features/Hosted_Engine_configuration_on_shared_storage When I check /etc/ovirt-hosted-engine/hosted-engine.conf there is no "conf_volume_UUID" entry. Do I need to create a shared config volume entry ( conf_volume_UUID ), so I can edit hosted engine VM? If so, how can this be done? I did try to rerun engine-setup, but this did not trigger anything. Kind regards, Paul Groeneweg Pazion ***disclaimer*** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation." -- Met vriendelijke groeten, Paul Groeneweg Pazion Webdevelopment - Hosting - Apps T +31 26 3020038 M +31 614 277 577 E paul(a)pazion.nl ***disclaimer*** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation."

3 13