5:51 p.m.
--_000_61A8344D117D814CA4DA393472F38CF4018F626E33CD1001M360cor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
I want to unmounted the hosted-engine NFS share without affecting all the o=
ther running VMs on the host. When I shutdown the hosted-engine and enable=
global maintenance, the storage pool is still mounted and I can't unmount =
it because the "sanlock" process is using it.
Is there any way to disconnect the storage pool? There is a hosted-engine =
--connect-storage option but I see nothing to disconnect it.
Thanks,
Ryan
--_000_61A8344D117D814CA4DA393472F38CF4018F626E33CD1001M360cor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
=
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META
HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator
content=3D"Micros=
oft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Century Gothic";
panose-1:2 11 5 2 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Century Gothic","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-CA
link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span
style=3D'f=
ont-size:10.0pt;font-family:"Century Gothic","sans-serif"'>I
want to unmoun=
ted the hosted-engine NFS share without affecting all the other running VMs=
on the host. When I shutdown the hosted-engine and enable global mai=
ntenance, the storage pool is still mounted and I can’t unmount it be=
cause the “sanlock” process is using
it.<o:p></o:p></span></p><=
p class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Century
Go=
thic","sans-serif"'><o:p> </o:p></span></p><p
class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Century
Gothic","sans-serif"'>Is the=
re any way to disconnect the storage pool? There is a hosted-engine -=
-connect-storage option but I see nothing to disconnect
it.<o:p></o:p></spa=
n></p><p class=3DMsoNormal><span
style=3D'font-size:10.0pt;font-family:"Cen=
tury
Gothic","sans-serif"'><o:p> </o:p></span></p><p
class=3DMsoNormal=
:10.0pt;font-family:"Century
Gothic","sans-serif"'>Ryan<o:p></o:p></span></=
p></div></body></html>=
--_000_61A8344D117D814CA4DA393472F38CF4018F626E33CD1001M360cor_--
12:03 p.m.
Thanks, RFE created (I hope I did it right)
https://bugzilla.redhat.com/show_bug.cgi?id=1145259
-----Original Message-----
From: Doron Fediuck [mailto:dfediuck@redhat.com]
Sent: September-21-14 6:57 AM
To: Groten, Ryan
Cc: users(a)ovirt.org
Subject: Re: [ovirt-users] How to disconnect hosted-engine NFS storage pool?
----- Original Message -----
Hi Ryan,
Hosted engine does not unmount the share since there may be other VMs using it (as a
general rule).
However this may deserve some additional thoughts. Do you mind opening an RFE for it?
4:07 a.m.
Hello Ryan and Doron,
Indeed a useful feature, I ran into this issue but forgot to mail. I
think in reality it is already best practice to put hosted engine on its
own NFS share (iSCSI LUN, Gluster-Vol in the future). Should we make
this an requirement?
On 23.09.2014 08:02, Doron Fediuck wrote:
--
Daniel Helgenberger
m box bewegtbild GmbH
P: +49/30/2408781-22
F: +49/30/2408781-10
ACKERSTR. 19
D-10115 BERLIN
www.m-box.de www.monkeymen.tv
Geschäftsführer: Martin Retschitzegger / Michaela Göllner
Handeslregister: Amtsgericht Charlottenburg / HRB 112767
6:06 a.m.
On 23.09.2014 11:51, Doron Fediuck wrote:
Hello Doron,
makes absolutely sense (at least for developers who need to test things
a lot ;)
From a practical point of view though it will always a bit different
as
long as you do not plan major design changes with hosted-engine because
of the potential lockout problem (engine-ha and shutdown / reboot, IIRC
right now no management other then migration from within ovirt). I know
you will have engine more 'manageable' form oVirt itself in the future,
but for the following reasons this is not very important for me:
Since in a worst case scenario engine is crustal getting tings working
again, 'users' (at least me) would tend to use a much simpler/robust
setup for engine storage (for instance, plain nfs, gluster 'local'
cluster - one replicated brick per host, no dm-multipath ect.). As for
the storage of 'production' VMs other points tend to be more crucial
(performance, multiple pathes, easy provision and administration ...).
My point being, common sense suggests you setup engine storage different
from 'production' storage.
Daniel
--
Daniel Helgenberger
m box bewegtbild GmbH
P: +49/30/2408781-22
F: +49/30/2408781-10
ACKERSTR. 19
D-10115 BERLIN
www.m-box.de www.monkeymen.tv
Geschäftsführer: Martin Retschitzegger / Michaela Göllner
Handeslregister: Amtsgericht Charlottenburg / HRB 112767
7:13 a.m.
----- Original Message -----
Daniel,
keeping the engine VM as close to the others is not only done
from the developer perspective, but rather from an admin perspective
as well. ie- try to keep things simple as much as possible.
Every admin may have his own way of managing the system, and
this is perfectly fine. So taking precaution by having a special
NFS share makes sense, and would be a good best practice.
Thanks for the feedback!
Doron
3849
days inactive
3854
days old
7 comments
3 participants
participants (3)
-
Daniel Helgenberger -
Doron Fediuck -
Groten, Ryan