- Users - oVirt List Archives

oVirt Live USB3 question
by Michael McConachie 26 Jun '17

26 Jun '17

--_000_DM5PR03MB263695A8C2F650880DC40D8B8CD90DM5PR03MB2636namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Potentially stupid question here. Sorry in advance if so. I have always bu= ilt out full blown multi rack instances of oVirt, and RHEV for clients, but= the following question has me wondering before I go digging and trying it = out... I realize that the oVirtLive ISO is for demo purposes, sandboxing, and not = production: I have a client, who is in need of a bootable AIO-based USB ins= tall with the caveat of being able to connect to the computer's HD and othe= r external storage at that point (for the Storage and ISO domains that I'll= create afterwards). This is because they have one BM to work with and the= y don't want the extra overhead using an SSD HD slot. They don't want to us= e a Sata DOM either if possible. In saying that, and concerning the oVirt LiveISO capabilities - I have two = questions. - Does the AIO USB install load necessary runtimes into memory, similar to = esxi bootable USBs and utilize the base hardware afterwards so that the res= t of the operations are ran in memory, hitting the disk (USB in this case) = like a normal OS load when needed for kernel calls, etc..?? - Are there a terrible performance costs if we stay with USB3 (which has a = ridiculous theoretical speed in certain hardware matching situations)? Thanks in advance for anyone who might have already crossed this bridge and= can provide insight. Michael J. McConachie | keys.fedoraproject.org | PubKey: 0x7BCD88F8 NOTE: The information included and/or attached in this electronic mail tran= smission may contain confidential or privileged information and is intended= solely for the addressee(s). Any unauthorized disclosure, reproduction, di= stribution or the taking of action in reliance on the contents of the infor= mation are strictly prohibited. If you have received the message in error, = please notify the sender by reply transmission and delete the message witho= ut copying, disclosing or forwarding. --_000_DM5PR03MB263695A8C2F650880DC40D8B8CD90DM5PR03MB2636namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:'Courier New',monospace;" dir=3D"ltr"> Hi all, Potentially stupid question here. Sorry in advance if so.  I have a= lways built out full blown multi rack instances of oVirt, and RHEV for clie= nts, but the following question has me wondering before I go digging and tr= ying it out... I realize that the oVirtLive ISO is for demo purposes, sandboxing, and n= ot production: I have a client, who is in need of a bootable AIO-based USB = install with the caveat of being able to connect to the computer's HD and o= ther external storage at that point (for the Storage and ISO domains that I'll create afterwards).  This = is because they have one BM to work with and they don't want the extra= overhead using an SSD HD slot. They don't want to use a Sata DOM either if= possible. In saying that, and concerning the oVirt LiveISO capabilities -&nbs= p;I have two questions. - Does the AIO USB install load necessary runtimes into memory, similar = to esxi bootable USBs and utilize the base hardware afterwards so that the = rest of the operations are ran in memory, hitting the disk (USB in this cas= e) like a normal OS load when needed for kernel calls, etc..?? - Are there a terrible performance costs if we stay with USB3 (which has= a ridiculous theoretical speed in certain hardware matching situations)?</= p> Thanks in advance for anyone who might have already crossed this bridge = and can provide insight. <div id=3D"Signature"> <pre> Mic= hael J. McConachie | keys.fedoraproject.org <font= style=3D"" color=3D"#000000">| PubKey: 0x7BCD88F8 = </pre> NOTE: The information included and/or a= ttached in this electronic mail transmission may contain confidential or pr= ivileged information and is intended solely for the addressee(s). Any unaut= horized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you = have received the message in error, please notify the sender by reply transmission and delete the message without copying, d= isclosing or forwarding. </div> </div> </body> </html> --_000_DM5PR03MB263695A8C2F650880DC40D8B8CD90DM5PR03MB2636namp_--

2 1

Hot Memory add and Physical Memory guaranteed
by Luca 'remix_tj' Lorenzetto 26 Jun '17

26 Jun '17

Hello, i just tested the memory hot add to a vm. This vm had 2048 MB. I set the new memory to 2662 MB. I logged into the vm and i've seen that hasn't been any memory change, even if i said to the manager to apply memory expansion immediately. Memory shown by free -m is 1772 MB. Looking around i've found that that value was set in the option called "Physical Memory guaranteed". I tried setting this parameter to an higher value, but is still showing 1772, even if it says that "Memory" parameter will be changed immediately and minAllocatedMemory is changed at next boot. What is the right workflow to hot increase the ram of a vm? Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

3 6

Ovirt adding routes
by Alan Griffiths 26 Jun '17

26 Jun '17

Hi, When installing an ovirt host I got these routes automatically added default dev ovirtmgmt table 2886865805 scope link 172.18.19.128/26 via 172.18.19.141 dev ovirtmgmt table 2886865805 What is their intended purpose? It seems to be stopping packets from being correctly routed to the local gateway. Thanks, Alan

2 2

import and old datadomain
by Ben De Luca 26 Jun '17

26 Jun '17

Hey, So, our DR plans included the idea of importing old domains. Is that meant to work now? -ben *very tired sysadmin*

2 2

migrating VMS from old hosted engine to new hosted engine
by Paul Groeneweg | Pazion 26 Jun '17

26 Jun '17

We are moving our VMs from an old 3.6 oVirt platform to a new oVirt 4.1 platform. I am looking for an easy way to migrate the VMs. ( I know about export domain, but this takes 2 times a copy action ) I tested and just detaching the Data domain and attaching it, didn't work. Then I found the VM import option: - Adding a ssh key gen and setting password on virsh - load a list of machines in the webinterface from VM import - when I start an import the system complains: The following VMs retrieved from external server qemu+ssh://root@xxx.xxx.xxx.xxx/system are not in down status: VM [VM-NAME]. - I tried to suspend the VM, but this didn;t work either ( same error ) - Problem is ,when VM is shutdown, it disappears from this system list. Is there a way to directly import a VM from old oVirt platform to the new platform Looking forward to find a solution to quickly migrate our VMs. Best Regards, Paul Groeneweg

3 3

Very big device. Trying to use READ CAPACITY
by Iman Darabi 26 Jun '17

26 Jun '17

hi. i'm using ovirt version 4.0 . I've created two LUNs. firs lun is 2047GB and working properly as data domain. but when i try to add second lun as second data domain, i get this error on server: Jun 21 13:22:41 compute52 kernel: sd 12:0:0:16384: [sdf] Very big device. Trying to use READ CAPACITY(16). Jun 21 13:22:41 compute52 kernel: sd 5:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Jun 21 13:22:41 compute52 kernel: sd 12:0:1:16384: [sdg] Very big device. Trying to use READ CAPACITY(16). Jun 21 13:22:41 compute52 kernel: sd 5:0:1:0: [sdc] Very big device. Trying to use READ CAPACITY(16). Jun 21 13:22:41 compute52 kernel: sd 12:0:0:0: [sdd] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 21 13:22:41 compute52 kernel: sd 12:0:0:0: [sdd] Sense Key : Illegal Request [current] Jun 21 13:22:41 compute52 kernel: sd 12:0:0:0: [sdd] Add. Sense: Logical unit not supported Jun 21 13:22:41 compute52 kernel: sd 12:0:1:0: [sde] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 21 13:22:41 compute52 kernel: sd 12:0:1:0: [sde] Sense Key : Illegal Request [current] Jun 21 13:22:41 compute52 kernel: sd 12:0:1:0: [sde] Add. Sense: Logical unit not supported Jun 21 13:22:41 compute52 kernel: device-mapper: table: 253:16: multipath: error getting device Jun 21 13:22:41 compute52 kernel: device-mapper: ioctl: error adding target to table Jun 21 13:22:41 compute52 multipathd: dm-16: remove map (uevent) Jun 21 13:22:41 compute52 multipathd: dm-16: remove map (uevent) error shows that second lun is very big device, but i've created second lun as 10GB for test. BTW: is there any good documentation for ovirt and FC in detail. all administration docs are using GUI ... . -- R&D expert at Ferdowsi University of Mashhad https://ir.linkedin.com/in/imandarabi <https://www.linkedin.com/profile/public-profile-settings?trk=prof-edit-edit…>

2 8

Re: [ovirt-users] VM live migration and NFS 4.2
by Markus Stockhausen 26 Jun '17

26 Jun '17

------=_NextPartTM-000-e1c15413-104b-461e-a7cc-b2d505c0c434 Content-Type: multipart/alternative; boundary="_000_7e055b7632964615b6e8181e0a661cd0emailandroidcom_" --_000_7e055b7632964615b6e8181e0a661cd0emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCml0cyBhbiBDZW50b3MgYmFzZWQgTkZTLiBZZXMgSSBoYXZlIFNFTGludXggcGVybWlz c2lvbnMgbmZzX3QgYWN0aXZlLiBPdGhlcndpc2Ugc2FubG9jayBmYWlscyBpbW1lZGlhdGVseSBh ZnRlciBzdG9yYWdlIGRvbWFpbiBhY3RpdmF0aW9uLg0KDQpNYXliZSBhbm90aGVyIFNFTGludXgg b3B0aW9uIG9yIHNvbWUga2luZCBvZiBuZXcgbG9ja2luZz8NCg0KTWFya3VzDQoNCkFtIDI2LjA2 LjIwMTcgOToyMiB2b3JtLiBzY2hyaWViIFlhbml2IEthdWwgPHlrYXVsQHJlZGhhdC5jb20+Og0K DQoNCk9uIFN1biwgSnVuIDI1LCAyMDE3IGF0IDEwOjMxIFBNLCBNYXJrdXMgU3RvY2toYXVzZW4g PHN0b2NraGF1c2VuQGNvbGxvZ2lhLmRlPG1haWx0bzpzdG9ja2hhdXNlbkBjb2xsb2dpYS5kZT4+ IHdyb3RlOg0KSGksDQoNCndlIGFyZSBjdXJyZW50bHkgZXZhbHVhdGluZyBORlMgNC4yIGJhc2Vk IHN0b3JhZ2UgZm9yIE9WaXJ0IDQuMS4yLiBOb3JtYWwgb3BlcmF0aW9uDQphbmQgZGlzY2FyZCBz dXBwb3J0IHdvcmsgbGlrZSBhIGNoYXJtLg0KDQpGb3Igc29tZSBzdHJhbmdlIHJlYXNvbiB3ZSBj YW5ub3QgdXNlIFZNIGxpdmUgbWlncmF0aW9uIGFueSBtb3JlLiBBcyBzb29uIGFzIG9uZQ0KTkZT IDQuMiBiYXNlZCBWTSBkaXNrIGlzIGRvaW5nIGRpc2sgSS9PIGR1cmluZyB0aGUgb3BlcmF0aW9u LiBWTSBzdGFsbHMgYW5kIGlzIHBhdXNlZC4NCkl0IHNlZW1zIGFzIGlmIHFlbXUgb24gdGFyZ2V0 IG5vZGUgY2Fubm90IHRha2Ugb3ZlciBkaXNrIGltYWdlcy4gU2VlIEJaMTQ2NDc4Ny4NCg0KQ2Fu IHlvdSBtYWtlIHN1cmUgeW91IGFyZSBub3Qgc3VmZmVyaW5nIGZyb20gYW55IFNFTGludXggaXNz dWVzPw0KV2hhdCBORlMgc2VydmVyIGFyZSB5b3UgdXNpbmc/IElmIGl0J3MgTGludXggYmFzZWQs IGl0IG5lZWRzIHNvbWUgc2VsaW51eCBjb21tYW5kcy4NCkZvciBleGFtcGxlIChmcm9tIG92aXJ0 LXN5c3RlbS10ZXN0cyk6DQogICAgc2VtYW5hZ2UgZmNvbnRleHQgLWEgLXQgbmZzX3QgJy9leHBv cnRzL25mcygvLiopPycNCiAgICByZXN0b3JlY29uIC1SdiAvZXhwb3J0cy9uZnMNCg0KDQpIYXMg YW55Ym9keSBlbHNlIHNlZW4gc2ltaWxhciBpc3N1ZXM/DQoNClJhej8NClkuDQoNCg0KQmVzdCBy ZWdhcmRzLg0KDQpNYXJrdXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpVc2VycyBtYWlsaW5nIGxpc3QNClVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNl cnNAb3ZpcnQub3JnPg0KaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vz ZXJzDQoNCg0KDQo= --_000_7e055b7632964615b6e8181e0a661cd0emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <386F76CBA452124689B36B083509DCE5(a)collogia.de> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPkhpLA0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPml0 cyBhbiBDZW50b3MgYmFzZWQgTkZTLiBZZXMgSSBoYXZlIFNFTGludXggcGVybWlzc2lvbnMgbmZz X3QgYWN0aXZlLiBPdGhlcndpc2Ugc2FubG9jayBmYWlscyBpbW1lZGlhdGVseSBhZnRlciBzdG9y YWdlIGRvbWFpbiBhY3RpdmF0aW9uLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2 Pg0KPGRpdiBkaXI9ImF1dG8iPk1heWJlIGFub3RoZXIgU0VMaW51eCBvcHRpb24gb3Igc29tZSBr aW5kIG9mIG5ldyBsb2NraW5nPzwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPk1hcmt1czwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPkFtIDI2LjA2LjIwMTcgOToyMiB2 b3JtLiBzY2hyaWViIFlhbml2IEthdWwgJmx0O3lrYXVsQHJlZGhhdC5jb20mZ3Q7OjxiciB0eXBl PSJhdHRyaWJ1dGlvbiI+DQo8YmxvY2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46 MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4N CjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2Pjxicj4NCjxkaXYgY2xhc3M9ImVsaWRl ZC10ZXh0Ij5PbiBTdW4sIEp1biAyNSwgMjAxNyBhdCAxMDozMSBQTSwgTWFya3VzIFN0b2NraGF1 c2VuIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c3RvY2toYXVzZW5AY29s bG9naWEuZGUiPnN0b2NraGF1c2VuQGNvbGxvZ2lhLmRlPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4IHNvbGlkIHJnYiggMjA0ICwgMjA0ICwgMjA0ICk7cGFkZGluZy1sZWZ0OjFleCI+DQpI aSw8YnI+DQo8YnI+DQp3ZSBhcmUgY3VycmVudGx5IGV2YWx1YXRpbmcgTkZTIDQuMiBiYXNlZCBz dG9yYWdlIGZvciBPVmlydCA0LjEuMi4gTm9ybWFsIG9wZXJhdGlvbjxicj4NCmFuZCBkaXNjYXJk IHN1cHBvcnQgd29yayBsaWtlIGEgY2hhcm0uPGJyPg0KPGJyPg0KRm9yIHNvbWUgc3RyYW5nZSBy ZWFzb24gd2UgY2Fubm90IHVzZSBWTSBsaXZlIG1pZ3JhdGlvbiBhbnkgbW9yZS4gQXMgc29vbiBh cyBvbmU8YnI+DQpORlMgNC4yIGJhc2VkIFZNIGRpc2sgaXMgZG9pbmcgZGlzayBJL08gZHVyaW5n IHRoZSBvcGVyYXRpb24uIFZNIHN0YWxscyBhbmQgaXMgcGF1c2VkLjxicj4NCkl0IHNlZW1zIGFz IGlmIHFlbXUgb24gdGFyZ2V0IG5vZGUgY2Fubm90IHRha2Ugb3ZlciBkaXNrIGltYWdlcy4gU2Vl IEJaMTQ2NDc4Ny48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5D YW4geW91IG1ha2Ugc3VyZSB5b3UgYXJlIG5vdCBzdWZmZXJpbmcgZnJvbSBhbnkgU0VMaW51eCBp c3N1ZXM/PC9kaXY+DQo8ZGl2PldoYXQgTkZTIHNlcnZlciBhcmUgeW91IHVzaW5nPyBJZiBpdCdz IExpbnV4IGJhc2VkLCBpdCBuZWVkcyBzb21lIHNlbGludXggY29tbWFuZHMuPC9kaXY+DQo8ZGl2 PkZvciBleGFtcGxlIChmcm9tIG92aXJ0LXN5c3RlbS10ZXN0cyk6PC9kaXY+DQo8ZGl2PiZuYnNw OyAmbmJzcDsgc2VtYW5hZ2UgZmNvbnRleHQgLWEgLXQgbmZzX3QgJy9leHBvcnRzL25mcygvLiop Pyc8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyByZXN0b3JlY29uIC1SdiAvZXhwb3J0cy9uZnM8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoIDIwNCAsIDIwNCAsIDIwNCAp O3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KSGFzIGFueWJvZHkgZWxzZSBzZWVuIHNpbWlsYXIg aXNzdWVzPzxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJhej88 L2Rpdj4NCjxkaXY+WS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoIDIw NCAsIDIwNCAsIDIwNCApO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KQmVzdCByZWdhcmRzLjxi cj4NCjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+DQpNYXJrdXMmbmJzcDsgPC9mb250Pjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19fX188YnI+ DQpVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VXNlcnNAb3ZpcnQub3Jn Ij5Vc2Vyc0BvdmlydC5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIj5odHRwOi8vbGlzdHMub3ZpcnQub3JnLzx3YnI+bWFp bG1hbi9saXN0aW5mby91c2VyczwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7e055b7632964615b6e8181e0a661cd0emailandroidcom_-- ------=_NextPartTM-000-e1c15413-104b-461e-a7cc-b2d505c0c434 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-e1c15413-104b-461e-a7cc-b2d505c0c434--

1 0

VM live migration and NFS 4.2
by Markus Stockhausen 26 Jun '17

26 Jun '17

This is a multi-part message in MIME format. ------=_NextPartTM-000-43bd1b86-b37d-4e90-be0e-0009cc3cc1fc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=0A= =0A= we are currently evaluating NFS 4.2 based storage for OVirt 4.1.2. Normal o= peration=0A= and discard support work like a charm. =0A= =0A= For some strange reason we cannot use VM live migration any more. As soon a= s one =0A= NFS 4.2 based VM disk is doing disk I/O during the operation. VM stalls and= is paused. =0A= It seems as if qemu on target node cannot take over disk images. See BZ1464= 787. =0A= =0A= Has anybody else seen similar issues?=0A= =0A= Best regards. =0A= =0A= Markus = ------=_NextPartTM-000-43bd1b86-b37d-4e90-be0e-0009cc3cc1fc Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-43bd1b86-b37d-4e90-be0e-0009cc3cc1fc--

2 1

hosted engine local disk estimate for OVA file
by Ben De Luca 25 Jun '17

25 Jun '17

Hi, I am in the middle of a disaster recovery situation trying to install ovirt 4.1 after a failure of some of our NFS systems. So I was redeploying 4.0 but there is a bug with the image uploader, that means I cant upload images. Our actually virtual machine hosts have very small HD's and the current 4.1 release installer thinks that the OVA extracted is 50GiB, I have exactly 50GB free! yay. So I did manage to hack the installer, to ignore my local disk space as the OVA is really only a few gigs in side. But its been pretty painful. Any chance of some one fixing the estimate there, I have read through the code, there was an attempt to find out the real size but they gave up and just guessed. -bd *tired sysadmin*

3 3

Re: [ovirt-users] VDSM ConnectStorageServerVDS failed
by Elad Ben Aharon 25 Jun '17

25 Jun '17

You're welcome On Sun, Jun 25, 2017 at 12:38 PM, JC Clark <jc(a)mcsaipan.net> wrote: > Mr Aharon, > > Thank you for an expedient reply. Your suggestions pointed me in the > right direction. I was concentrating on the Hosts when it was the storage > I should have paid more attention to. It seems that if any one of the > Storage Domains is not connecting properly, the system refuses to restore. > > It turns out that after the power failure, an inconspicuous server had not > come up properly. It had the ISO Domain and an unused Data Domain which > was still attached. These caused the failure. BZ to you sir and good day. > > Thank you > > > > On 06/25/2017 06:54 PM, Elad Ben Aharon wrote: > > Hi, > > Which types of storage do you have in the data center? > > In case it's a block based storage (iSCSI/FC), check that the devices > (LUNs) where you domains reside are accessible though multipath and LVM: > > # multipath -ll > # pvs > # vgs > > In case it's a file based storage (NFS/GlusterFS), check that the storage > domain file system is mounted under /rhev/data-center/mnt > > # mount | grep '/rhev/data-center' > > On Sun, Jun 25, 2017 at 11:29 AM, JC Clark <jc(a)mcsaipan.net> wrote: > >> Dear All, >> >> Is there a reason that a perfectly well working Ovirt 4.1 Engine after a >> power failure, would not allow the hosts to activate because of "VDSM >> ConnectStorageServerVDS failed". All firewalls are down, I have >> reinstalled the host, upgraded everything (host and engine), deleted and >> reinstalled hosts, I can ssh to all from all. Any clues?? >> >> Thanks ahead of time.. >> >> -- >> Warm Regards, >> JC Clark >> IT Director >> Mount Carmel School >> Saipan, CNMI >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > > > > -- > Warm Regards, > > JC Clark > IT Director > Mount Carmel School > Saipan, CNMI > (670) 235-6272 office(670) 483-8684 cell > >

1 0