Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 97CB618577 for ; Thu, 10 Sep 2015 06:44:39 +0000 (UTC) Received: (qmail 91354 invoked by uid 500); 10 Sep 2015 06:44:38 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 91299 invoked by uid 500); 10 Sep 2015 06:44:38 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 91276 invoked by uid 99); 10 Sep 2015 06:44:38 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Sep 2015 06:44:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3C2B7C0233 for ; Thu, 10 Sep 2015 06:44:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id JCGFjN86A0XH for ; Thu, 10 Sep 2015 06:44:22 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 7F16520C24 for ; Thu, 10 Sep 2015 06:44:22 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so10836236wic.0 for ; Wed, 09 Sep 2015 23:44:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-type; bh=jgJEtci6NOz7MQhkl74jlMNK6y4wITsZnmmedjFnQsM=; b=iPInztu/zdBGaaX2M7FrppLj7/hK6RzLy1qlk461NuQkolPJxCq44dlUeamWb0ZvgA YsTkWG2bzF7GcP4Cl3m595LHWs792gFziqJLbmI01Rjq9bRWmzUlMwaOCVyExg6JsLtu OrUP+QAvAqTKJ7U4sbqvD1cVjP5m3P4KwiqeFfF4aXQnnyJeUDEyz9IdNXwwnLzqN4rw n5IfQPhKHK4eDyihgFMU35TptRvY8TtALEnMkEp1A6ILeu1E0DVSAW3F6lonKA3RVtvt 0zo+kass4vGICXtHeWhAJG1vfLe/vb1dwYe+umbxQoF2cDDyBX+yroRMNOYQPrPDDxAz Tctg== X-Gm-Message-State: ALoCoQnomkF9bsWhT2KHz8NrzT0f1vWWlzTQMLU5pl//K4afRjk2PLhLwehzjC3MCaW0MWx2yzCv X-Received: by 10.194.238.202 with SMTP id vm10mr59400799wjc.96.1441867456453; Wed, 09 Sep 2015 23:44:16 -0700 (PDT) Received: from [10.0.0.32] (ntelligence.de. [217.8.60.230]) by smtp.gmail.com with ESMTPSA id bi6sm13883308wjc.25.2015.09.09.23.44.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Sep 2015 23:44:15 -0700 (PDT) Subject: Re: Zookeeper in a VM To: user@zookeeper.apache.org References: From: =?UTF-8?Q?J=c3=bcrgen_Wagner_=28DVT=29?= X-Enigmail-Draft-Status: N1110 Message-ID: <55F126C0.6050807@devoteam.com> Date: Thu, 10 Sep 2015 08:44:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------010301010804010405000705" --------------010301010804010405000705 Content-Type: multipart/alternative; boundary="------------090508090208090906080604" --------------090508090208090906080604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Bill, we are running Zk in VMs without problems. Each VM gets an internal IP address (e.g., to talk to its host, like the private range address you have in your log file) and an external IP address (to reach out from the VM host environment, usually also a private one in the 10.x.x.x range). The latter is fixed, the former may change depending on the host where the VM runs and what the DHCP server thinks is available. Consequently, the host name of the VM should be bound to the external IP address. Additionally, as we generate the Zk config files automatically through centralized provisioning, we use (the external) IP addresses in the config files, rather than host names. There used to be issues with name resolution, so this is safer and changes will be reflected through the provisioning engine, anyway. Cheers, --Jürgen >>>> Hi All >>>> >>>> I am running ZK as a 3 node cluster. Each ZK instance is a VMWare VM in >>>> a >>>> distinct ESX host. Let's assume the three VMs are A, B and C where A is >>>> the >>>> leader. Now if I take down VM B and C and then bring one of them back >>>> up. >>>> However the ZK cluster is never formed unless I bounce VM A. How can I >>>> troubleshoot this? This however does not happen in a physical >>>> environment. >>>> >>>> -- >>>> Cheers >>>> Bill >>>> -- Mit freundlichen Grüßen/Kind regards/Cordialement vôtre/Atentamente/С уважением *i.A. Jürgen Wagner* Head of Competence Center "Intelligence" & Senior Cloud Consultant Devoteam GmbH, Industriestr. 3, 70565 Stuttgart, Germany Phone: +49 6151 868-8725, Fax: +49 711 13353-53, Mobile: +49 171 864 1543 E-Mail: juergen.wagner@devoteam.com , URL: www.devoteam.de ------------------------------------------------------------------------ Managing Board: Jürgen Hatzipantelis (CEO) Address of Record: 64331 Weiterstadt, Germany; Commercial Register: Amtsgericht Darmstadt HRB 6450; Tax Number: DE 172 993 071 --------------090508090208090906080604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Bill,
  we are running Zk in VMs without problems. Each VM gets an internal IP address (e.g., to talk to its host, like the private range address you have in your log file) and an external IP address (to reach out from the VM host  environment, usually also a private one in the 10.x.x.x range). The latter is fixed, the former may change depending on the host where the VM runs and what the DHCP server thinks is available. Consequently, the host name of the VM should be bound to the external IP address.

Additionally, as we generate the Zk config files automatically through centralized provisioning, we use (the external) IP addresses in the config files, rather than host names. There used to be issues with name resolution, so this is safer and changes will be reflected through the provisioning engine, anyway.

Cheers,
--Jürgen

Hi All

I am running ZK as a 3 node cluster. Each ZK instance is a VMWare VM in
a
distinct ESX host. Let's assume the three VMs are A, B and C where A is
the
leader. Now if I take down VM B and C and then bring one of them back
up.
However the ZK cluster is never formed unless I bounce VM A. How can I
troubleshoot this? This however does not happen in a physical
environment.

--
Cheers
Bill



--

Mit freundlichen Grüßen/Kind regards/Cordialement vôtre/Atentamente/С уважением
i.A. Jürgen Wagner
Head of Competence Center "Intelligence"
& Senior Cloud Consultant

Devoteam GmbH, Industriestr. 3, 70565 Stuttgart, Germany
Phone: +49 6151 868-8725, Fax: +49 711 13353-53, Mobile: +49 171 864 1543
E-Mail: juergen.wagner@devoteam.com, URL: www.devoteam.de


Managing Board: Jürgen Hatzipantelis (CEO)
Address of Record: 64331 Weiterstadt, Germany; Commercial Register: Amtsgericht Darmstadt HRB 6450; Tax Number: DE 172 993 071


--------------090508090208090906080604-- --------------010301010804010405000705--