Re: [ceph-users] PG calculator improvement
Hello Frédéric, Thank you very much for the input. I would like to ask for some feedback from you, as well as the ceph-users list at large. The PGCalc tool was created to help steer new Ceph users in the right direction, but it's certainly difficult to account for every possible scenario. I'm struggling to find a way to implement something that would work better for the scenario that you (Frédéric) describe, while still being a useful starting point for the novice / more mainstream use cases. I've also gotten complaints at the other end of the spectrum, that the tool expects the user to know too much already, so accounting for the number of objects is bound to add to this sentiment. As the Ceph user base expands and the use cases diverge, we are definitely finding more edge cases that are causing pain. I'd love to make something to help prevent these types of issues, but again, I worry about the complexity introduced. With this, I see a few possible ways forward: * Simply re-wroding the %data to be % object count -- but this seems more abstract, again leading to more confusion of new users. * Increase complexity of the PG Calc tool, at the risk of further alienating novice/mainstream users * Add a disclaimer about the tool being a base for decision making, but that certain edge cases require adjustments to the recommended PG count and/or ceph.conf & sysctl values. * Add a disclaimer urging the end user to secure storage consulting if their use case falls into certain categories or they are new to Ceph to ensure the cluster will meet their needs. Having been on the storage consulting team and knowing the expertise they have, I strongly believe that newcomers to Ceph (or new use cases inside of established customers) should secure consulting before final decisions are made on hardware... let alone the cluster is deployed. I know it seems a bit self-serving to make this suggestion as I work at Red Hat, but there is a lot on the line when any establishment is storing potentially business critical data. I suspect the answer lies in a combination of the above or in something I've not thought of. Please do weigh in as any and all suggestions are more than welcome. Thanks, Michael J. Kidd Principal Software Maintenance Engineer Red Hat Ceph Storage +1 919-442-8878 On Wed, Apr 12, 2017 at 6:35 AM, Frédéric Nass < frederic.n...@univ-lorraine.fr> wrote: > > Hi, > > I wanted to share a bad experience we had due to how the PG calculator > works. > > When we set our production cluster months ago, we had to decide on the > number of PGs to give to each pool in the cluster. > As you know, the PG calc would recommended to give a lot of PGs to heavy > pools in size, regardless the number of objects in the pools. How bad... > > We essentially had 3 pools to set on 144 OSDs : > > 1. a EC5+4 pool for the radosGW (.rgw.buckets) that would hold 80% of all > datas in the cluster. PG calc recommended 2048 PGs. > 2. a EC5+4 pool for zimbra's data (emails) that would hold 20% of all > datas. PG calc recommended 512 PGs. > 3. a replicated pool for zimbra's metadata (null size objects holding > xattrs - used for deduplication) that would hold 0% of all datas. PG calc > recommended 128 PGs, but we decided on 256. > > With 120M of objects in pool #3, as soon as we upgraded to Jewel, we hit > the Jewel scrubbing bug (OSDs flapping). > Before we could upgrade to patched Jewel, scrub all the cluster again > prior to increasing the number of PGs on this pool, we had to take more > than a hundred of snapshots (for backup/restoration purposes), with the > number of objects still increasing in the pool. Then when a snapshot was > removed, we hit the current Jewel snap trimming bug affecting pools with > too many objects for the number of PGs. The only way we could stop the > trimming was to stop OSDs resulting in PGs being degraded and not trimming > anymore (snap trimming only happens on active+clean PGs). > > We're now just getting out of this hole, thanks to Nick's post regarding > osd_snap_trim_sleep and RHCS support expertise. > > If the PG calc had considered not only the pools weight but also the > number of expected objects in the pool (which we knew by that time), we > wouldn't have it these 2 bugs. > We hope this will help improving the ceph.com and RHCS PG calculators. > > Regards, > > Frédéric. > > -- > > Frédéric Nass > > Sous-direction Infrastructures > Direction du Numérique > Université de Lorraine > > Tél : +33 3 72 74 11 35 > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Javascript error at http://ceph.com/pgcalc/
Hello John, Thanks for the bug report. Unfortunately, I'm not able to reproduce the error. I tested from both Firefox and Chrome on linux. Can you let me know what os/browser you're using? Also, I've not tested any non 'en-US' characters, so I can't attest to how it will behave with other alphabets. Thanks, Michael J. Kidd Sr. Software Maintenance Engineer Red Hat Ceph Storage +1 919-442-8878 <(919)%20442-8878> On Wed, Jan 11, 2017 at 6:01 PM, 林自均 wrote: > Hi Michael, > > Thanks for your link! > > However, when I am using your clone of pgcalc, the newly created pool > didn't follow my values in the "Add Pool" dialog. For example, no matter > what I fill in "Pool Name", I always get "newPool" as the name. > > By the way, where can I find the git repository of pgcalc? I can't find it > at https://github.com/ceph/. Thanks! > > Best, > John Lin > > Michael Kidd 於 2017年1月12日 週四 上午7:02寫道： > >> Hello John, >> Apologies for the error. We will be working to correct it, but in the >> interim, you can use http://linuxkidd.com/ceph/pgcalc.html >> >> Thanks, >> >> Michael J. Kidd >> Sr. Software Maintenance Engineer >> Red Hat Ceph Storage >> +1 919-442-8878 <(919)%20442-8878> >> >> On Wed, Jan 11, 2017 at 12:03 AM, 林自均 wrote: >> >> Hi all, >> >> I am not sure if this is the correct mailing list. Correct me if I am >> wrong. >> >> I failed to add a pool at http://ceph.com/pgcalc/ because of a >> Javascript error: >> >> (index):345 Uncaught TypeError: $(...).dialog is not a function >> at addPool (http://ceph.com/pgcalc/:345:31) >> at HTMLButtonElement.onclick (http://ceph.com/pgcalc/:534:191) >> >> Where can I report this error? Thanks. >> >> Best, >> John Lin >> >> ___ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >> >> ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Javascript error at http://ceph.com/pgcalc/
Hello John, Apologies for the error. We will be working to correct it, but in the interim, you can use http://linuxkidd.com/ceph/pgcalc.html Thanks, Michael J. Kidd Sr. Software Maintenance Engineer Red Hat Ceph Storage +1 919-442-8878 On Wed, Jan 11, 2017 at 12:03 AM, 林自均 wrote: > Hi all, > > I am not sure if this is the correct mailing list. Correct me if I am > wrong. > > I failed to add a pool at http://ceph.com/pgcalc/ because of a Javascript > error: > > (index):345 Uncaught TypeError: $(...).dialog is not a function > at addPool (http://ceph.com/pgcalc/:345:31) > at HTMLButtonElement.onclick (http://ceph.com/pgcalc/:534:191) > > Where can I report this error? Thanks. > > Best, > John Lin > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Calculating PG in an mixed environment
Hello Martin, The proper way is to perform the following process: For all Pools utilizing the same bucket of OSDs: (Pool1_pg_num * Pool1_size) + (Pool2_pg_num * Pool2_size) + ... (Pool(n)_pg_num * Pool(n)_size) -- OSD count This value should be between 100 and 200 PGs and is the actual ratio of PGs per OSD in that bucket of OSDs. For the actual recommendation from Ceph Devs (and written by myself), please see: http://ceph.com/pgcalc/ NOTE: The tool is partially broken, but the explanation at the top/bottom is sound. I'll work to get the tool fully functional again. Thanks, Michael J. Kidd Sr. Software Maintenance Engineer Red Hat Ceph Storage +1 919-442-8878 On Tue, Mar 15, 2016 at 11:41 AM, Martin Palma wrote: > Hi all, > > The documentation [0] gives us the following formula for calculating > the number of PG if the cluster is bigger than 50 OSDs: > > (OSDs * 100) > Total PGs = > pool size > > When we have mixed storage server (HDD disks and SSD disks) and we > have defined different roots in our crush map to map some pools only > to HDD disk and some to SSD disks like described by Sebastien Han [1]. > > In the above formula what number of OSDs should be use to calculate > the PGs for a pool only on the HDD disks? The total number of OSDs in > a cluster or only the number of OSDs which have an HDD disk as > backend? > > Best, > Martin > > > [0] > http://docs.ceph.com/docs/master/rados/operations/placement-groups/#choosing-the-number-of-placement-groups > [1] > http://www.sebastien-han.fr/blog/2014/08/25/ceph-mix-sata-and-ssd-within-the-same-box/ > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Why is this pg incomplete?
Bryan, If you can read the disk that was osd.102, you may wish to attempt this process to recover your data: https://ceph.com/community/incomplete-pgs-oh-my/ Good luck! Michael J. Kidd Sr. Software Maintenance Engineer Red Hat Ceph Storage On Mon, Jan 4, 2016 at 8:32 AM, Bryan Wright wrote: > Gregory Farnum writes: > > > I can't parse all of that output, but the most important and > > easiest-to-understand bit is: > > "blocked_by": [ > > 102 > > ], > > > > And indeed in the past_intervals section there are a bunch where it's > > just 102. You really want min_size >=2 for exactly this reason. :/ But > > if you get 102 up stuff should recover; if you can't you can mark it > > as "lost" and RADOS ought to resume processing, with potential > > data/metadata loss... > > -Greg > > > > > Ack! I thought min_size was 2, but I see: > > ceph osd pool get data min_size > min_size: 1 > > Well that's a fine kettle of fish. > > The osd in question (102) has actually already been marked as lost, via > "ceph osd lost 102 --yes-i-really-mean-it", and it shows up in "ceph osd > tree" as "DNE". If I can manage to read the disk, how should I try to add > it back in? > > > > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] ceph-mon always election when change crushmap in firefly
Hello Alexander, One other point on your email.. You indicate you desire each OSD to have ~100 PGs, but depending on your pool size, it seems you may have forgetting about the additional PGs associated with replication itself. Assuming 3x replication in your environment: 70,000 * 3 800 OSDs =~ 262.5 PGs per OSD on average While this PG to OSD ratio shouldn't cause significant pain, I would not go to any higher PG count without adding more spindles. For more specific PG count guidance and modeling, please see: http://ceph.com/pgcalc Hope this helps, Michael J. Kidd Sr. Storage Consultant Red Hat Global Storage Consulting +1 919-442-8878 On Wed, Sep 23, 2015 at 8:34 AM, Sage Weil wrote: > On Wed, 23 Sep 2015, Alexander Yang wrote: > > hello, > > We use Ceph+Openstack in our private cloud. In our cluster, we > have > > 5 mons and 800 osds, the Capacity is about 1Pb. And run about 700 vms and > > 1100 volumes, > > recently, we increase our pg_num , now the cluster have about > 7 > > pgs. In my real intention? I want every osd have 100pgs. but after > increase > > pg_num, I find I'm wrong. Because the different crush weight for > different > > osd, the osd's pg_num is different, some osd have exceed 500pgs. > > Now, the problem is appear?cause some reason when i want to > change > > some osd weight, that means change the crushmap. This change cause > about > > 0.03% data to migrate. the mon is always begin to election. It's will > hung > > the cluster, and when they end, the original leader still is the new > > leader. And during the mon eclection?On the upper layer, vm have too many > > slow request will appear. so now i dare to do any operation about change > > crushmap. But i worry about an important thing, If when our cluster > down > > one host even down one rack. By the time, the cluster curshmap will > > change large, and the migrate data also large. I worry the cluster will > > hung long time. and result on upper layer, all vm became to shutdown. > > In my opinion, I guess when I change the crushmap,* the leader > mon > > maybe calculate the too many information*, or* too many client want to > get > > the new crushmap from leader mon*. It must be hung the mon thread, so > the > > leader mon can't heatbeat to other mons, the other mons think the leader > is > > down then begin the new election. I am sorry if i guess is wrong. > > The crushmap in accessory. So who can give me some advice or > guide, > > Thanks very much! > > There were huge improvements made in hammer in terms of mon efficiency in > these cases where it is under load. I recommend upgrading as that will > help. > > You can also mitigate the problem somewhat by adjusting the mon_lease and > associated settings up. Scale all of mon_lease, mon_lease_renew_interval, > mon_lease_ack_timeout, mon_accept_timeout by 2x or 3x. > > It also sounds like you may be using some older tunables/settings > for your pools or crush rules. Can you attach the output of 'ceph osd > dump' and 'ceph osd crush dump | tail -n 20' ? > > sage > ___ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > ___ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Re: [ceph-users] Firefly - Giant : CentOS 7 : install failed ceph-deploy
For Firefly / Giant installs, I've had success with the following: yum install ceph ceph-common --disablerepo=base --disablerepo=epel Let us know if this works for you as well. Thanks, Michael J. Kidd Sr. Storage Consultant Inktank Professional Services - by Red Hat On Wed, Apr 8, 2015 at 8:55 PM, Travis Rhoden wrote: > I did also confirm that, as Ken mentioned, this is not a problem on Hammer > since Hammer includes the package split (python-ceph became python-rados > and python-rbd). > > - Travis > > On Wed, Apr 8, 2015 at 5:00 PM, Travis Rhoden wrote: > >> Hi Vickey, >> >> The easiest way I know of to get around this right now is to add the >> following line in section for epel in /etc/yum.repos.d/epel.repo >> >> exclude=python-rados python-rbd >> >> So this is what my epel.repo file looks like: http://fpaste.org/208681/ >> >> It is those two packages in EPEL that are causing problems. I also tried >> enabling epel-testing, but that didn't work either. >> >> Unfortunately you would need to add this line on each node where Ceph >> Giant is being installed. >> >> - Travis >> >> On Wed, Apr 8, 2015 at 4:11 PM, Vickey Singh > > wrote: >> >>> Community , need help. >>> >>> >>> -VS- >>> >>> On Wed, Apr 8, 2015 at 4:36 PM, Vickey Singh < >>> vickey.singh22...@gmail.com> wrote: >>> Any suggestion geeks VS On Wed, Apr 8, 2015 at 2:15 PM, Vickey Singh < vickey.singh22...@gmail.com> wrote: > > Hi > > > The below suggestion also didn’t worked > > > Full logs here : http://paste.ubuntu.com/10771939/ > > > > > [root@rgw-node1 yum.repos.d]# yum --showduplicates list ceph > > Loaded plugins: fastestmirror, priorities > > Loading mirror speeds from cached hostfile > > * base: mirror.zetup.net > > * epel: ftp.fi.muni.cz > > * extras: mirror.zetup.net > > * updates: mirror.zetup.net > > 25 packages excluded due to repository priority protections > > Available Packages > > ceph.x86_64 > 0.80.6-0.el7.centos > Ceph > > ceph.x86_64 > 0.80.7-0.el7.centos > Ceph > > ceph.x86_64 > 0.80.8-0.el7.centos > Ceph > > ceph.x86_64 > 0.80.9-0.el7.centos > Ceph > > [root@rgw-node1 yum.repos.d]# > > > > > > Its not able to install latest available package , yum is getting > confused with other DOT releases. > > > Any other suggestion to fix this ??? > > > > --> Processing Dependency: libboost_system-mt.so.1.53.0()(64bit) for > package: librbd1-0.80.9-0.el7.centos.x86_64 > > --> Processing Dependency: libboost_thread-mt.so.1.53.0()(64bit) for > package: librbd1-0.80.9-0.el7.centos.x86_64 > > --> Finished Dependency Resolution > > Error: Package: librbd1-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: libboost_system-mt.so.1.53.0()(64bit) > > Error: Package: ceph-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: libboost_system-mt.so.1.53.0()(64bit) > > Error: Package: ceph-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: libaio.so.1(LIBAIO_0.4)(64bit) > > Error: Package: ceph-common-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: libboost_thread-mt.so.1.53.0()(64bit) > > Error: Package: ceph-common-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: librados2 = 0.80.7-0.el7.centos > >Available: librados2-0.80.6-0.el7.centos.x86_64 (Ceph) > >librados2 = 0.80.6-0.el7.centos > >Available: librados2-0.80.7-0.el7.centos.x86_64 (Ceph) > >librados2 = 0.80.7-0.el7.centos > >Available: librados2-0.80.8-0.el7.centos.x86_64 (Ceph) > >librados2 = 0.80.8-0.el7.centos > >Installing: librados2-0.80.9-0.el7.centos.x86_64 (Ceph) > >librados2 = 0.80.9-0.el7.centos > > Error: Package: libcephfs1-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: libboost_thread-mt.so.1.53.0()(64bit) > > Error: Package: ceph-common-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: python-requests > > Error: Package: ceph-common-0.80.7-0.el7.centos.x86_64 (Ceph) > >Requires: librbd1 = 0.80.7-0.el7.centos > >Available: librbd1-0.80.6-0.el7.centos.x86_64 (Ceph) > >librbd1 = 0.80.6-0.el7.centos > >Available: librbd1-0.80.7-0.el7.centos.x86_64 (Ceph) > >librbd1 = 0.80.7-0.el7.centos > >Available: librbd1-0.80.8-0.el7.centos.x86_64 (Ceph) > >librbd1 = 0.80.8-0.el7.centos > >Installing: librbd1-0.80.9-0.el7.centos.x86_64 (Ceph) > >
Re: [ceph-users] Firefly - Giant : CentOS 7 : install failed ceph-deploy
I don't think this came through the first time.. resending.. If it's a dupe, my apologies.. For Firefly / Giant installs, I've had success with the following: yum install ceph ceph-common --disablerepo=base --disablerepo=epel Let us know if this works for you as well. Thanks, Michael J. Kidd Sr. Storage Consultant Inktank Professional Services - by Red Hat On Wed, Apr 8, 2015 at 9:07 PM, Michael Kidd wrote: > For Firefly / Giant installs, I've had success with the following: > > yum install ceph ceph-common --disablerepo=base --disablerepo=epel > > Let us know if this works for you as well. > > Thanks, > > Michael J. Kidd > Sr. Storage Consultant > Inktank Professional Services > - by Red Hat > > On Wed, Apr 8, 2015 at 8:55 PM, Travis Rhoden wrote: > >> I did also confirm that, as Ken mentioned, this is not a problem on >> Hammer since Hammer includes the package split (python-ceph became >> python-rados and python-rbd). >> >> - Travis >> >> On Wed, Apr 8, 2015 at 5:00 PM, Travis Rhoden wrote: >> >>> Hi Vickey, >>> >>> The easiest way I know of to get around this right now is to add the >>> following line in section for epel in /etc/yum.repos.d/epel.repo >>> >>> exclude=python-rados python-rbd >>> >>> So this is what my epel.repo file looks like: http://fpaste.org/208681/ >>> >>> It is those two packages in EPEL that are causing problems. I also >>> tried enabling epel-testing, but that didn't work either. >>> >>> Unfortunately you would need to add this line on each node where Ceph >>> Giant is being installed. >>> >>> - Travis >>> >>> On Wed, Apr 8, 2015 at 4:11 PM, Vickey Singh < >>> vickey.singh22...@gmail.com> wrote: >>> >>>> Community , need help. >>>> >>>> >>>> -VS- >>>> >>>> On Wed, Apr 8, 2015 at 4:36 PM, Vickey Singh < >>>> vickey.singh22...@gmail.com> wrote: >>>> >>>>> Any suggestion geeks >>>>> >>>>> >>>>> VS >>>>> >>>>> On Wed, Apr 8, 2015 at 2:15 PM, Vickey Singh < >>>>> vickey.singh22...@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> The below suggestion also didn’t worked >>>>>> >>>>>> >>>>>> Full logs here : http://paste.ubuntu.com/10771939/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [root@rgw-node1 yum.repos.d]# yum --showduplicates list ceph >>>>>> >>>>>> Loaded plugins: fastestmirror, priorities >>>>>> >>>>>> Loading mirror speeds from cached hostfile >>>>>> >>>>>> * base: mirror.zetup.net >>>>>> >>>>>> * epel: ftp.fi.muni.cz >>>>>> >>>>>> * extras: mirror.zetup.net >>>>>> >>>>>> * updates: mirror.zetup.net >>>>>> >>>>>> 25 packages excluded due to repository priority protections >>>>>> >>>>>> Available Packages >>>>>> >>>>>> ceph.x86_64 >>>>>> 0.80.6-0.el7.centos >>>>>> Ceph >>>>>> >>>>>> ceph.x86_64 >>>>>> 0.80.7-0.el7.centos >>>>>> Ceph >>>>>> >>>>>> ceph.x86_64 >>>>>> 0.80.8-0.el7.centos >>>>>> Ceph >>>>>> >>>>>> ceph.x86_64 >>>>>> 0.80.9-0.el7.centos >>>>>> Ceph >>>>>> >>>>>> [root@rgw-node1 yum.repos.d]# >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Its not able to install latest available package , yum is getting >>>>>> confused with other DOT releases. >>>>>> >>>>>> >>>>>> Any other suggestion to fix this ??? >>>>>> >>>>>> >>>>>> >>>>>> --> Processing Dependency: libboost_system-mt.so.1.53.0()(64bit) for >>>>>> package: librbd1-0.80.9-0.el7.centos.x86_64 >>>>>> >>>>>> --> Processing Dependen
Re: [ceph-users] mon add problem
This indicates you have multiple networks on the new mon host, but no
definition in your ceph.conf as to which network is public.
In your ceph.conf, add:
public network = 192.168.1.0/24
cluster network = 192.168.2.0/24
(Fix the subnet definitions for your environment)
Then, re-try your new mon deploy.
Thanks,
Michael J. Kidd
Michael J. Kidd
Sr. Storage Consultant
Inktank Professional Services
On Mon, Dec 16, 2013 at 4:27 PM, Umar Draz wrote:
> Hi,
>
> I am try to add mon host using ceph-deploy mon create kvm2, but its not
> working and giving me an error.
>
> [kvm2][DEBUG ] determining if provided host has same hostname in remote
> [kvm2][DEBUG ] get remote short hostname
> [kvm2][DEBUG ] deploying mon to kvm2
> [kvm2][DEBUG ] get remote short hostname
> [kvm2][DEBUG ] remote hostname: kvm2
> [kvm2][DEBUG ] write cluster configuration to /etc/ceph/{cluster}.conf
> [kvm2][DEBUG ] create the mon path if it does not exist
> [kvm2][DEBUG ] checking for done path: /var/lib/ceph/mon/ceph-kvm2/done
> [kvm2][DEBUG ] create a done file to avoid re-doing the mon deployment
> [kvm2][DEBUG ] create the init path if it does not exist
> [kvm2][DEBUG ] locating the `service` executable...
> [kvm2][INFO ] Running command: initctl emit ceph-mon cluster=ceph id=kvm2
> [kvm2][INFO ] Running command: ceph --cluster=ceph --admin-daemon
> /var/run/ceph/ceph-mon.kvm2.asok mon_status
> [kvm2][ERROR ] admin_socket: exception getting command descriptions:
> [Errno 2] No such file or directory
> [kvm2][WARNIN] monitor: mon.kvm2, might not be running yet
> [kvm2][INFO ] Running command: ceph --cluster=ceph --admin-daemon
> /var/run/ceph/ceph-mon.kvm2.asok mon_status
> [kvm2][ERROR ] admin_socket: exception getting command descriptions:
> [Errno 2] No such file or directory
> [kvm2][WARNIN] kvm2 is not defined in `mon initial members`
> [kvm2][WARNIN] monitor kvm2 does not exist in monmap
> [kvm2][WARNIN] neither `public_addr` nor `public_network` keys are defined
> for monitors
> [kvm2][WARNIN] monitors may not be able to form quorum
> root@kvm1:/home/umar/ceph-cluster# ceph-deploy mon create kvm2
>
>
> would you please help me how to solve this problem?
>
> Br.
>
> Umar
>
> ___
> ceph-users mailing list
> ceph-users@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>
>
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
