Re: [Users] HA schema for ovirt?
by Perry Myers
On 11/04/2011 05:46 PM, José Román Bilbao wrote:
> Thanks for the info. I am committed to help on this, but I don't know
> where to start... Can you point me on the right direction?
Depends on what your short term priority is. Could be any one of the
following areas:
* Helping to write an upstream whitepaper/wiki on using standard
clustering solutions to make oVirt Engine HA. Brandon Perkins from Red
Hat wrote something up specific to RHEL, perhaps you could help him with
a POC using Pacemaker in a distro like Ubuntu or SLES. (Brandon said
he'd handle the writeup of Fedora HA + oVirt Engine)
* Helping the oVirt Engine team with leveraging app server clustering to
make the engine HA aware. I don't know the details here, so your best
path is to join the engine-devel mailing list and start submitting small
patches on the engine in order to better learn the codebase so that you
can then help with larger features like this
* Helping the vdsm team with implementing node policy for moving some HA
features to the endpoints instead of needing the engine. Joining
vdsm-devel(a)lists.fedorahosted.org and starting to learn the codebase
there by submitting some small patches to start with is a good idea
Basically, start small. Push some patches upstream to show that you
have a good understanding of the codebase, and then start writing up
proposals for the upstream list that outline how you think best to
tackle some of these more advanced features. Certainly, implementing
engine HA or vdsm policy is not a trivial exercise, so it will involve
input and development from many people.
Hope that helps
Perry
> Thanks,
>
> Jode
>
> El 04/11/2011 17:11, "Perry Myers" <pmyers(a)redhat.com
> <mailto:pmyers@redhat.com>> escribió:
>
> > As one of my priorities on a virtualization platform is to offer HA, I
> > wanted to know how does it work on the ovirt architecture. I mean,
> I my
> > management node fails, is HA still running on the ovirt-nodes (is
> > distributed ) or is it manager dependent?
>
> Right now if the oVirt Engine server fails, HA of the guests running on
> oVirt Nodes will not work. This is because the oVirt Engine is what
> coordinates monitoring and restart of the guests marked as HA.
>
> Today, the best way to protect against that double-failure is to provide
> HA for the oVirt Engine itself. This can be done by setting up a 2 node
> HA cluster via a HA stack like Pacemaker or RHEL Clustering. Pacemaker
> is in lots of distributions, so this is a fairly ubiquitous way of
> providing HA for non-HA aware services.
>
> In the future, the goal is to make the oVirt Engine HA aware via
> something similar to JBoss clustering combined with database
> replication/clustering. This will remove the need for a separate HA
> stack.
>
> Also, my understanding is that the roadmap for vdsm is to provide it
> with more intelligence/policies so that it can take care of some of the
> HA features even in the absence of the oVirt Engine running.
>
> The enhanced vdsm for policy/HA is a roadmap item, as is making the
> Engine HA aware. We could certainly use help implementing those
> items :)
>
12 years, 7 months
VDSM Sync call
by abaron@redhat.com
The following is a new meeting request:
Subject: VDSM Sync call
Organizer: "Ayal Baron" <abaron(a)redhat.com>
Location: intercall 8425973915
Time: 4:30:00 PM - 5:30:00 PM GMT +02:00 Jerusalem
Recurrence : Every 2 week(s) on Monday No end date Effective Jul 4, 2011
Invitees: vdsm-devel(a)lists.fedorahosted.org
*~*~*~*~*~*~*~*~*~*
This call is about vdsm development issues upstream going forward.
You are welcome to join.
Bridge ID: 8425973915
Dial-in information:
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679
Reservationless-Plus International Dial-In Number: (212) 729-5016
Conference code: 8425973915
Global Access Numbers Local:
Australia, Sydney Dial-In #: 0289852326
Austria, Vienna Dial-In #: 012534978196
Belgium, Brussels Dial-In #: 027920405
China Dial-In #: 4006205013
Denmark, Copenhagen Dial-In #: 32729215
Finland, Helsinki Dial-In #: 0923194436
France, Paris Dial-In #: 0170377140
Germany, Berlin Dial-In #: 030300190579
Ireland, Dublin Dial-In #: 014367793
Italy, Milan Dial-In #: 0236269529
Netherlands, Amsterdam Dial-In #: 0207975872
Norway, Oslo Dial-In #: 21033188
Singapore Dial-In #: 64840858
Spain, Barcelona Dial-In #: 935452328
Sweden, Stockholm Dial-In #: 0850513770
Switzerland, Geneva Dial-In #: 0225927881
United Kingdom Dial-In #: 02078970515
United Kingdom Dial-In #: 08445790676
United Kingdom, LocalCall Dial-In #: 08445790678
United States Dial-In #: 2127295016
Global Access Numbers Tollfree:
Argentina Dial-In #: 8004441016
Australia Dial-In #: 1800337169
Austria Dial-In #: 0800005898
Bahamas Dial-In #: 18002054776
Bahrain Dial-In #: 80004377
Belgium Dial-In #: 080048325
Brazil Dial-In #: 08008921002
Bulgaria Dial-In #: 008001100236
Chile Dial-In #: 800370228
Colombia Dial-In #: 018009134033
Costa Rica Dial-In #: 08000131048
Cyprus Dial-In #: 80095297
Czech Republic Dial-In #: 800700318
Denmark Dial-In #: 80887114
Dominican Republic Dial-In #: 18887512313
Estonia Dial-In #: 8000100232
Finland Dial-In #: 0800117116
France Dial-In #: 0805632867
Germany Dial-In #: 8006647541
Greece Dial-In #: 00800127562
Hong Kong Dial-In #: 800930349
Hungary Dial-In #: 0680016796
Iceland Dial-In #: 8008967
India Dial-In #: 0008006501533
Indonesia Dial-In #: 0018030179162
Ireland Dial-In #: 1800932401
Israel Dial-In #: 1809462557
Italy Dial-In #: 800985897
Jamaica Dial-In #: 18002050328
Japan Dial-In #: 0120934453
Korea (South) Dial-In #: 007986517393
Latvia Dial-In #: 80003339
Lithuania Dial-In #: 880030479
Luxembourg Dial-In #: 80026595
Malaysia Dial-In #: 1800814451
Mexico Dial-In #: 0018664590915
New Zealand Dial-In #: 0800888167
Norway Dial-In #: 80012994
Panama Dial-In #: 008002269184
Philippines Dial-In #: 180011100991
Poland Dial-In #: 008001210187
Portugal Dial-In #: 800814625
Russian Federation Dial-In #: 81080028341012
Saint Kitts and Nevis Dial-In #: 18002059252
Singapore Dial-In #: 8006162235
Slovak Republic Dial-In #: 0800001441
South Africa Dial-In #: 0800981148
Spain Dial-In #: 800300524
Sweden Dial-In #: 200896860
Switzerland Dial-In #: 800650077
Taiwan Dial-In #: 00801127141
Thailand Dial-In #: 001800656966
Trinidad and Tobago Dial-In #: 18002024615
United Arab Emirates Dial-In #: 8000650591
United Kingdom Dial-In #: 08006948057
United States Dial-In #: 8004518679
Uruguay Dial-In #: 00040190315
Venezuela Dial-In #: 08001627182
12 years, 7 months
EIO
by abaron@redhat.com
Hi Ricardo,
During the workshop you asked about qemu behavior once resuming a VM after EIO.
I went back to check and qemu never passes the EIO to the guest, instead it retries the I/O.
So it would seem that the current behavior should be fine (also with soft mounts).
Are there other error flows we should look into?
I seem to recall we discussed other issues as well, but I don't remember the specifics (jet lag).
Regards,
Ayal.
12 years, 7 months
A newbie of RHEV and An question about rhev hypervisor
by 李范茂
Hi all,
In my environment, I mapped two luns to rhev hypervisor through a single
HBA. I can see the two luns in hypervisor’s command line, but when new a
Storage Domain in RHEV Manager, the hypervisor can’t discover any of them.
Where can I find the error log ? And maybe I should configure something in
the hypervisor, if so could you show me the detailed configuration steps?
I’ll be very appreciate.
Thanks a lot & Best wishes.
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this communication in error,please
immediately notify the sender by return e-mail, and delete the original message and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------
12 years, 7 months