Very big device. Trying to use READ CAPACITY
by Iman Darabi
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-ed...>
8 years
Re: [ovirt-users] VM live migration and NFS 4.2
by Markus Stockhausen
------=_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--
8 years
VM live migration and NFS 4.2
by Markus Stockhausen
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--
8 years
hosted engine local disk estimate for OVA file
by Ben De Luca
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*
8 years
Re: [ovirt-users] VDSM ConnectStorageServerVDS failed
by Elad Ben Aharon
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
>
>
8 years
Re: [ovirt-users] VDSM ConnectStorageServerVDS failed
by Elad Ben Aharon
Can you please provide engine.log and vdsm.log?
On Sun, Jun 25, 2017 at 2:29 PM, JC Clark <jc(a)mcsaipan.net> wrote:
> Mr. Aharon,
>
> One question comes to mind, if the mounts don't mount to the rhev... mount
> point, what is the easiest way to rectify that problem?
>
>
>
> 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
>
>
8 years
VDSM ConnectStorageServerVDS failed
by JC Clark
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
8 years
Change HostedEngine Storage
by Matt .
Hi guys,
When you want to move your hosted_engine storage you can copy stuff
over but you still need to change the image which contains all config
files.
Is there some documentation about how to do so ?
Thanks,
Matt
8 years
Info on live snapshot and agent interaction
by Gianluca Cecchi
Hello,
supposing to have a Linux VM with ovirt-guest-agent installed, during a
live snapshot operation it should be freeze of filesystems.
Where to find confirmation of correct/successful interaction?
/var/log/messages or agent log or other kind of files?
Are there any limitations on filesystems that support freeze? Is it
fsfreeze the command executed at VM OS level or any other low level command?
Thanks,
Gianluca
8 years
