- Users - oVirt List Archives

Re: [ovirt-users] Hosted-Engine Deploy - Error Creating a Storage Domain
by Simone Tiraboschi 06 Jun '17

06 Jun '17

It seams something related to IOProcess connection. 2017-05-25 20:54:40,362-0700 INFO (jsonrpc/4) [IOProcessClient] Starting client ioprocess-3 (__init__:330) 2017-05-25 20:54:40,370-0700 INFO (ioprocess/31239) [IOProcess] Starting ioprocess (__init__:452) 2017-05-25 20:54:40,407-0700 ERROR (jsonrpc/4) [storage.TaskManager.Task] (Task='89dd17d2-8a38-4825-9ba2-f231f1aff9f5') Unexpected error (task:870) Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 877, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2581, in createStorageDomain storageType, domVersion) File "/usr/share/vdsm/storage/nfsSD.py", line 87, in create remotePath, storageType, version) File "/usr/share/vdsm/storage/fileSD.py", line 421, in _prepareMetadata procPool.fileUtils.createdir(metadataDir, 0o775) File "/usr/lib/python2.7/site-packages/vdsm/storage/outOfProcess.py", line 166, in createdir self._iop.mkdir(tmpPath, mode) File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 524, in mkdir self.timeout) File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 466, in _sendCommand raise OSError(errcode, errstr) OSError: [Errno 61] No data available 2017-05-25 20:54:40,409-0700 INFO (jsonrpc/4) [storage.TaskManager.Task] (Task='89dd17d2-8a38-4825-9ba2-f231f1aff9f5') aborting: Task is aborted: u'[Errno 61] No data available' - code 100 (task:1175) 2017-05-25 20:54:40,409-0700 ERROR (jsonrpc/4) [storage.Dispatcher] [Errno 61] No data available (dispatcher:80) Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 72, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 105, in wrapper return m(self, *a, **kw) File "/usr/share/vdsm/storage/task.py", line 1183, in prepare raise self.error OSError: [Errno 61] No data available 2017-05-25 20:54:40,410-0700 INFO (jsonrpc/4) [jsonrpc.JsonRpcServer] RPC call StorageDomain.create failed (error 351) in 0.24 seconds (__init__:533) Nir, any hint? On Wed, May 31, 2017 at 5:24 PM, Langley, Robert <Robert.Langley(a)ventura.org > wrote: > SOSReport attached, with md5. Thank you > > > > > > *From:* Sandro Bonazzola [mailto:sbonazzo@redhat.com] > *Sent:* Wednesday, May 31, 2017 12:00 AM > *To:* Langley, Robert <Robert.Langley(a)ventura.org>; Nir Soffer < > nsoffer(a)redhat.com>; Allon Mureinik <amureini(a)redhat.com>; Tal Nisan < > tnisan(a)redhat.com>; Simone Tiraboschi <stirabos(a)redhat.com> > *Cc:* users <users(a)ovirt.org> > *Subject:* Re: [ovirt-users] Hosted-Engine Deploy - Error Creating a > Storage Domain > > > > > > > > On Tue, May 30, 2017 at 11:50 PM, Langley, Robert < > Robert.Langley(a)ventura.org> wrote: > > While going through the hosted engine deployment, I am not able to have it > successfully complete. Even going through the setup log, I’m not able to > identify what is wrong. Why it thinks the system is not reliable. > > > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in > _executeMethod > > method['method']() > > File "/usr/share/ovirt-hosted-engine-setup/scripts/../ > plugins/gr-he-setup/storage/storage.py", line 957, in _misc > > self._createStorageDomain() > > File "/usr/share/ovirt-hosted-engine-setup/scripts/../ > plugins/gr-he-setup/storage/storage.py", line 546, in _createStorageDomain > > raise RuntimeError(status['status']['message']) > > RuntimeError: Error creating a storage domain: (u'storageType=7, > sdUUID=a2494209-f823-4745-8eea-a122889d48f6, domainName=hosted_storage, > domClass=1, typeSpecificArg=gsa-stor1.stor.local:/engine domVersion=3',) > > > > > > Can you please provide vdsm logs or better a full sos report (sosreport > -a)? > > > > > > > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > > > > > -- > > *SANDRO BONAZZOLA* > > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > > Red Hat EMEA <https://www.redhat.com/> > > [image: Image removed by sender.] <https://red.ht/sig> > > *TRIED. TESTED. TRUSTED.* <https://redhat.com/trusted> > > >

3 5

Docker images for oVirt engine
by Leni Kadali Mutungi 06 Jun '17

06 Jun '17

I noticed that there had been some discussion regarding Docker images in the devel mailing list. I wanted to confirm that this: https://github.com/oVirt/ovirt-container-engine is alright to use with Docker. If this isn't the official source to use, pointers in the right direction would appreciated. -- - Warm regards Leni Kadali Mutungi

4 15

Re: [ovirt-users] windows 2016 drivers
by Pavel Gashev 05 Jun '17

05 Jun '17

--_000_FA4B66D291C1419F95B063A868C53823acroniscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGhhdmUgdG8gc2V0IGNvbXBhdGliaWxpdHkgbW9kZSBmb3IgdGhlIHNldHVwIGZpbGUgdG8g V2luZG93cyA4IGF0IGxlYXN0Lg0KaHR0cHM6Ly9zdXBwb3J0Lm1pY3Jvc29mdC5jb20vZW4tdXMv aGVscC8xNTA3OC93aW5kb3dzLW1ha2Utb2xkZXItcHJvZ3JhbXMtY29tcGF0aWJsZQ0KDQpGcm9t OiA8dXNlcnMtYm91bmNlc0BvdmlydC5vcmc+IG9uIGJlaGFsZiBvZiAic3Vwb3J0ZUBsb2dpY3dv cmtzLnB0IiA8c3Vwb3J0ZUBsb2dpY3dvcmtzLnB0Pg0KRGF0ZTogTW9uZGF5LCA1IEp1bmUgMjAx NyBhdCAxNjo0Mg0KVG86IG92aXJ0IHVzZXJzIDx1c2Vyc0BvdmlydC5vcmc+DQpTdWJqZWN0OiBb b3ZpcnQtdXNlcnNdIHdpbmRvd3MgMjAxNiBkcml2ZXJzDQoNCkhpLA0KDQpPbiBWZXJzaW9uIDQu MS4xLjgtMS5lbDcuY2VudG9zLHdoZW4gdHJ5aW5nIHRvIGluc3RhbGwgb2lydC10b29sc1NldHVw LTQuMS0zLmZjMjQgb24gd2luZG93cyBzZXJ2ZXIgMjAxNiBnZXQgYW4gZXJyb3Igc2F5aW5nIG9w ZXJhdGluZyBzeXN0ZW0gbm90IGNvbXBhdGlibGUuDQpJIHdhcyBhYmxlIHRvIGluc3RhbGwgb1Zp cnQtdG9vbHNTZXR1cF80LjAtMS5mYzIyMyBidXQgd2hlbiB0cnlpbmcgdG8gdHJhbnNmZXIgZmls ZXMgdG8gdGhlIFZNIHRoZSBuZXR3b3JrIGdldHMgdG8gc2xvdyB1bnRpbCBpdCBzdG9wcy4NCg0K SXMgdzIwMTYgc3RpbGwgbm90IHN1cHBvcnRlZD8NCg0KVGhhbmtzDQoNCi0tDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSm9zZSBGZXJyYWRlaXJhDQpodHRwOi8vd3d3LmxvZ2lj d29ya3MucHQNCg== --_000_FA4B66D291C1419F95B063A868C53823acroniscom_ Content-Type: text/html; charset="utf-8" Content-ID: <C70FC06600134C4C9F32C49DDED9D517(a)acronis.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5 NS4wcHQgODQyLjBwdDsNCgltYXJnaW46Mi4wY20gNDIuNXB0IDIuMGNtIDMuMGNtO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPllvdSBoYXZlIHRvIHNldCBjb21wYXRpYmlsaXR5IG1v ZGUgZm9yIHRoZSBzZXR1cCBmaWxlIHRvIFdpbmRvd3MgOCBhdCBsZWFzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5odHRw czovL3N1cHBvcnQubWljcm9zb2Z0LmNvbS9lbi11cy9oZWxwLzE1MDc4L3dpbmRvd3MtbWFrZS1v bGRlci1wcm9ncmFtcy1jb21wYXRpYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Jmx0 O3VzZXJzLWJvdW5jZXNAb3ZpcnQub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7c3Vwb3J0ZUBs b2dpY3dvcmtzLnB0JnF1b3Q7ICZsdDtzdXBvcnRlQGxvZ2ljd29ya3MucHQmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPk1vbmRheSwgNSBKdW5lIDIwMTcgYXQgMTY6NDI8YnI+DQo8Yj5UbzogPC9iPm92 aXJ0IHVzZXJzICZsdDt1c2Vyc0BvdmlydC5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltv dmlydC11c2Vyc10gd2luZG93cyAyMDE2IGRyaXZlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj5PbiBWZXJzaW9uIDQuMS4xLjgtMS5lbDcuY2VudG9zLHdoZW4gdHJ5 aW5nIHRvIGluc3RhbGwgb2lydC10b29sc1NldHVwLTQuMS0zLmZjMjQgb24gd2luZG93cyBzZXJ2 ZXIgMjAxNiBnZXQgYW4gZXJyb3Igc2F5aW5nIG9wZXJhdGluZyBzeXN0ZW0gbm90IGNvbXBhdGli bGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkkgd2FzIGFi bGUgdG8gaW5zdGFsbCBvVmlydC10b29sc1NldHVwXzQuMC0xLmZjMjIzIGJ1dCB3aGVuIHRyeWlu ZyB0byB0cmFuc2ZlciBmaWxlcyB0byB0aGUgVk0gdGhlIG5ldHdvcmsgZ2V0cyB0byBzbG93IHVu dGlsIGl0IHN0b3BzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+SXMg dzIwMTYgc3RpbGwgbm90IHN1cHBvcnRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+ LS0gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Sm9zZSBGZXJyYWRl aXJhPGJyPg0KaHR0cDovL3d3dy5sb2dpY3dvcmtzLnB0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FA4B66D291C1419F95B063A868C53823acroniscom_--

1 0

disaster recovery, connecting to existing storage domains from new engine
by Thomas Wakefield 05 Jun '17

05 Jun '17

Is it possible to force a connection to existing storage domains from a new engine? I have a cluster that I can’t get the web console to restart, but everything else is working. So I want to know if it’s possible to just remount those storage domains to the new engine? Also, how do I clear an export domain that complains that it’s still attached to another pool? Because I could also just restore most of my VM’s from the export domain, but it is still locked to the old engine. Thanks!

1 0

windows 2016 drivers
by suporte＠logicworks.pt 05 Jun '17

05 Jun '17

------=_Part_4696045_1226233397.1496670149355 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, On Version 4.1.1.8-1.el7.centos,when trying to install oirt-toolsSetup-4.1-3.fc24 on windows server 2016 get an error saying operating system not compatible. I was able to install oVirt-toolsSetup_4.0-1.fc223 but when trying to transfer files to the VM the network gets to slow until it stops. Is w2016 still not supported? Thanks -- Jose Ferradeira http://www.logicworks.pt ------=_Part_4696045_1226233397.1496670149355 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: Times New Roman; font-size: 10pt; color: #000000"><div>Hi,<br></div><div><br data-mce-bogus="1"></div><div>On Version 4.1.1.8-1.el7.centos,when trying to install oirt-toolsSetup-4.1-3.fc24 on windows server 2016 get an error saying operating system not compatible.<br data-mce-bogus="1"></div><div>I was able to install oVirt-toolsSetup_4.0-1.fc223 but when trying to transfer files to the VM the network gets to slow until it stops.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Is w2016 still not supported?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div data-marker="__SIG_POST__">-- <br></div><div><hr style="width: 100%; height: 2px;">Jose Ferradeira<br>http://www.logicworks.pt<br></div></div></body></html> ------=_Part_4696045_1226233397.1496670149355--

3 4

Manually copying VM disks from FC data domain
by Николаев Алексей 05 Jun '17

05 Jun '17

2 6

Regarding wiki on Backup Storage
by shubham dubey 04 Jun '17

04 Jun '17

Hello, I just have put a PR for wiki on Backup Storage at ovirt-site[1]. The idea is to have a better backup solution for disaster recovery, in place of export storage domain. The idea is already discussed in mailing list earlier. Me and maor(as mentor) are working on this feature and till now I have done a push[2] for adding backup flag in database. I will appreciate everyone to review the wiki and share some feedback/comments about our implementation process. [1]:https://github.com/oVirt/ovirt-site/pull/1003 [2]:https://gerrit.ovirt.org/#/c/77142/ Thanks, Shubham

1 0

Re: [ovirt-users] VM/Template copy issue
by Bryan Sockel 04 Jun '17

04 Jun '17

This is a multi-part message in MIME format. ----_com.samsung.android.email_5990013383491030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This happening to a number of vm's. All vm's are running and can be stopped and re started. We can read and write data within the vm. All vms are currently running on a single node gluster file system. I am attempting to migrate to a replica 3 gluster file system when i exprience these issues. The problem always seems to happen when finalizing the move or copy. If it makes a difference the gluster storage we are coping to and from are dedicated storage servers. -------- Original message -------- From: Maor Lipchuk <mlipchuk(a)redhat.com> Date: 6/2/17 5:29 PM (GMT-06:00) To: Bryan Sockel <Bryan.Sockel(a)altn.com> Cc: users(a)ovirt.org Subject: Re: [ovirt-users] VM/Template copy issue _____ >From : Maor Lipchuk [mlipchuk(a)redhat.com] To : Bryan Sockel [Bryan.Sockel(a)altn.com] Cc : users(a)ovirt.org [users(a)ovirt.org] Date : Friday, June 2 2017 17:27:32 Hi Bryan, It seems like there was an error from qemu-img while reading sector 143654878 . the Image copy (conversion) failed with low level qemu-img failure: CopyImageError: low level Image copy failed: ("cmd=['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice', '-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'raw', u'/rhev/data-center/d776b537-16f2-4543-bd96-9b4cba69e247/e371d380-7194-4 950-b901-5f2aed5dfb35/images/9959c6e4-1fb7-455b-ad5e-8b9e2324a0ab/3f4e18 3b-7957-4bee-9153-9d967491f882', '-O', 'raw', u'/rhev/data-center/mnt/glusterSD/vs-host-colo-1-gluster.altn.int:_deskt op-vdi1/f927ceb8-91d2-41bd-ba42-dc795395b6d0/images/9959c6e4-1fb7-455b-a d5e-8b9e2324a0ab/3f4e183b-7957-4bee-9153-9d967491f882'], ecode=1, stdout=, stderr=qemu-img: error while reading sector 143654878: No data available\n, message=None",) Can you verify those disks are indeed valid? Can you IO to them while attaching them to a running VM? On Tue, May 30, 2017 at 9:10 PM, Bryan Sockel wrote: > > Hi, > > I am trying to rebuild my ovirt environment after having to juggle some > hardware around. I am moving from hosted engine environment into a engine > install on a dedicated server. I have two data centers in my setup and each > DC has a non-routable vlan dedicated to storage. > > As i rebuild my setup i am trying to clean up my storage configuration. I > am attempting to copy vm's and templates to a dedicated gluster setup. > However each time i attempt to copy a template or move a vm, the operation > fails. The failure always happens when it is finalizing the copy. > > The operation does not happen with all vm's, but seems to happen mostly with > vm's created from with in Ovirt, and not imported from vmware. > > > I have attached the logs from where i was trying to copy to templates to a > new Gluster Filesystem > > Thanks > Bryan > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ----_com.samsung.android.email_5990013383491030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3DUTF-8"></head><body><div>This happening to a number  of = vm's. All vm's are running and can be stopped and re started.  We = can read and write data within the vm.</div><div><br></div><div>All vms = are currently running on a single node gluster file system.  I am = attempting to migrate to a replica 3 gluster file system when i = exprience these issues.  The problem always seems to happen when = finalizing the move or copy.</div><div><br></div><div>If it makes a = difference the gluster storage we are coping to and from are dedicated = storage servers.</div><div><br></div><div><br></div><div>-------- Original message --------</div><div>From: Maor Lipchuk = <mlipchuk(a)redhat.com> </div><div>Date: 6/2/17 5:29 PM = (GMT-06:00) </div><div>To: Bryan Sockel <Bryan.Sockel(a)altn.com> = </div><div>Cc: users(a)ovirt.org </div><div>Subject: Re: [ovirt-users] = VM/Template copy issue </div><div><br></div><div = style=3D"margin-left:2px;padding-left:2px;border-left:1px solid = #202020;"><div style=3D"font-size: 10pt; background-color: #ffffff; = color: #000000; font-weight: 400; font-family: = Tahoma,Arial,Verdana,sans-serif;" ><hr /><div><span = style=3D"font-weight: 700">From</span> : Maor Lipchuk = [mlipchuk(a)redhat.com]</div><div><span style=3D"font-weight: = 700">To</span> : Bryan Sockel [Bryan.Sockel(a)altn.com]</div><div><span = style=3D"font-weight: 700">Cc</span> : users(a)ovirt.org = [users(a)ovirt.org]</div><div><span style=3D"font-weight: 700">Date</span> = : Friday, June 2 2017 17:27:32</div></div>=0A= <pre>Hi Bryan, It seems like there was an error from qemu-img while reading sector = 143654878 . the Image copy (conversion) failed with low level qemu-img failure: CopyImageError: low level Image copy failed: ("cmd=3D['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice', '-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'raw', u'/rhev/data-center/d776b537-16f2-4543-bd96-9b4cba69e247/e371d380-7194-49= 50-b901-5f2aed5dfb35/images/9959c6e4-1fb7-455b-ad5e-8b9e2324a0ab/3f4e183b= -7957-4bee-9153-9d967491f882', '-O', 'raw', = u'/rhev/data-center/mnt/glusterSD/vs-host-colo-1-gluster.altn.int:_deskto= p-vdi1/f927ceb8-91d2-41bd-ba42-dc795395b6d0/images/9959c6e4-1fb7-455b-ad5= e-8b9e2324a0ab/3f4e183b-7957-4bee-9153-9d967491f882'], ecode=3D1, stdout=3D, stderr=3Dqemu-img: error while reading sector 143654878: No data available\n, message=3DNone",) Can you verify those disks are indeed valid? Can you IO to them while attaching them to a running VM? On Tue, May 30, 2017 at 9:10 PM, Bryan Sockel <Bryan.Sockel(a)altn.com> = wrote: > > Hi, > > I am trying to rebuild my ovirt environment after having to juggle = some > hardware around. I am moving from hosted engine environment into a = engine > install on a dedicated server. I have two data centers in my setup = and each > DC has a non-routable vlan dedicated to storage. > > As i rebuild my setup i am trying to clean up my storage = configuration. I > am attempting to copy vm's and templates to a dedicated gluster setup. > However each time i attempt to copy a template or move a vm, the = operation > fails. The failure always happens when it is finalizing the copy. > > The operation does not happen with all vm's, but seems to happen = mostly with > vm's created from with in Ovirt, and not imported from vmware. > > > I have attached the logs from where i was trying to copy to templates = to a > new Gluster Filesystem > > Thanks > Bryan > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > </pre></div></body></html> ----_com.samsung.android.email_5990013383491030--

2 1

Snapshot Image ID
by Marcelo Leandro 04 Jun '17

04 Jun '17

Good morning, I have a problem with snapshot, my last snapshot that should have the image base ID not contain this reference in sub-tab in the dashboard. how can see in the picture attached. I think that is necessary add this reference in the database again. The image exist in the storage and it is used for VM execution, but i think when I shutdown the VM it not start anymore. someone help me? Thanks, Marcelo Leandro

3 3

Storage domain does not exist
by Bryan Sockel 04 Jun '17

04 Jun '17

Hey, I am having an issue moving/copying vm's and templates around in my ovirt environment. I am getting the following error in my VDSM Logs: "2017-06-01 01:01:54,425-0500 ERROR (jsonrpc/5) [storage.Dispatcher] {'status': {'message': "Storage domain does not exist: (u'97258ca6-5acd-40c7-a812-b8cac02a9621',)", 'code': 358}} (dispatcher:77)" I believe this started when i destroyed a data domain instead of removing the domain correctly. I have since then rebuilt my ovirt environment, importing my gluster domains back into my new setup. I believe the issue is related to some stale metadata on my gluster storage servers somewhere but do not know how to remove it or where it exists. I found these two posts that seem to deal with the same problem i am seeing. https://access.redhat.com/solutions/180623 and https://access.redhat.com/solutions/2355061 Currently running 2 dedicated gluster servers and 2 Ovirt VM hosts servers, one is acting as an arbiter for my replica 3 gluster file system. All hosts are running CentOS Linux release 7.3.1611 (Core) Thanks

2 1