Hi all,
I would like to have my home dir at cephfs and to keep selinux enabled
at the same time.
The trouble is selinux prevents sshd to access ~/.ssh/authorized_keys
file. Any ideas how to fix it?
I have mimic installed and for some reason the dashboard isn't showing up.
I see which mon is listed as active for "mgr", the module is enabled, but
nothing is listening on port 8080:
# ceph mgr module ls
{
"enabled_modules": [
"dashboard",
"iostat",
"status"
tcp 0 0 10.8.152.4:6800 0.0.0.0:* LISTEN
69049/ceph-mgr
Hi, i'm integrating ceph like glance's backend, my Openstack is stein over Ubuntu 18.04. When I try upload an image rados.py have an error when calls "run_in_thread()" function (line 238). I've tried use rados mudule from python3 interface and i have the same issue.
I read that Python 3 has different behaviour of ctypes c_char_p.
How can I resolve that issue??
I copy that example:
admin@control1:~$ sudo python3
[sudo] password for admin:
Python 3.6.8 (default, Aug 20 2019, 17:12:48)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import rados
>>> cluster = rados.Rados(conffile='')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.6/dist-packages/rados.py", line 239, in __init__
(byref(self.cluster), c_char_p(clustername)),
TypeError: bytes or integer address expected instead of str instance
This is the fourth release in the Ceph Nautilus stable release series. Its sole
purpose is to fix a regression that found its way into the previous release.
Notable Changes
---------------
The ceph-volume in Nautilus v14.2.3 was found to contain a serious
regression, described in https://tracker.ceph.com/issues/41660, which
prevented deployment tools like ceph-ansible, DeepSea, Rook, etc. from
deploying/removing OSDs.
Getting Ceph
------------
* Git at git://github.com/ceph/ceph.git
* Tarball at http://download.ceph.com/tarballs/ceph-14.2.3.tar.gz
* For packages, see http://docs.ceph.com/docs/master/install/get-packages/
* Release git sha1: 75f4de193b3ea58512f204623e6c5a16e6c1e1ba
--
Abhishek Lekshmanan
SUSE Software Solutions Germany GmbH
Hi,
I have defined pool hdd which is exclusively used by virtual disks of
multiple KVMs / LXCs.
Yesterday I run these commands
osdmaptool om --upmap out.txt --upmap-pool hdd
source out.txt
and Ceph started rebalancing this pool.
However since then no KVM / LXC is reacting anymore.
If I try to start a new KVM it hangs in boot process.
This is the output of ceph health detail:
root@ld3955:/mnt/rbd# ceph health detail
HEALTH_ERR 28 nearfull osd(s); 1 pool(s) nearfull; Reduced data
availability: 1 pg inactive, 1 pg peering; Degraded data redundancy (low
space): 8 pgs backfill_toofull; 1 subtrees have overcommitted pool
target_size_bytes; 1 subtrees have overcommitted pool target_size_ratio;
2 pools have too many placement groups; 672 slow requests are blocked >
32 sec; 4752 stuck requests are blocked > 4096 sec
OSD_NEARFULL 28 nearfull osd(s)
osd.42 is near full
osd.44 is near full
osd.45 is near full
osd.77 is near full
osd.84 is near full
osd.94 is near full
osd.101 is near full
osd.103 is near full
osd.106 is near full
osd.109 is near full
osd.113 is near full
osd.118 is near full
osd.120 is near full
osd.136 is near full
osd.138 is near full
osd.142 is near full
osd.147 is near full
osd.156 is near full
osd.159 is near full
osd.161 is near full
osd.168 is near full
osd.192 is near full
osd.202 is near full
osd.206 is near full
osd.208 is near full
osd.226 is near full
osd.234 is near full
osd.247 is near full
POOL_NEARFULL 1 pool(s) nearfull
pool 'hdb_backup' is nearfull
PG_AVAILABILITY Reduced data availability: 1 pg inactive, 1 pg peering
pg 30.1b9 is stuck peering for 4722.750977, current state peering,
last acting [183,27,63]
PG_DEGRADED_FULL Degraded data redundancy (low space): 8 pgs
backfill_toofull
pg 11.465 is active+remapped+backfill_wait+backfill_toofull, acting
[308,351,58]
pg 11.5c4 is active+remapped+backfill_wait+backfill_toofull, acting
[318,336,54]
pg 11.afd is active+remapped+backfill_wait+backfill_toofull, acting
[347,220,315]
pg 11.b82 is active+remapped+backfill_toofull, acting [314,320,254]
pg 11.1803 is active+remapped+backfill_wait+backfill_toofull, acting
[88,363,302]
pg 11.1aac is active+remapped+backfill_wait+backfill_toofull, acting
[328,275,95]
pg 11.1c09 is active+remapped+backfill_wait+backfill_toofull, acting
[55,124,278]
pg 11.1e36 is active+remapped+backfill_wait+backfill_toofull, acting
[351,92,315]
POOL_TARGET_SIZE_BYTES_OVERCOMMITTED 1 subtrees have overcommitted pool
target_size_bytes
Pools ['hdb_backup'] overcommit available storage by 1.708x due to
target_size_bytes 0 on pools []
POOL_TARGET_SIZE_RATIO_OVERCOMMITTED 1 subtrees have overcommitted pool
target_size_ratio
Pools ['hdb_backup'] overcommit available storage by 1.708x due to
target_size_ratio 0.000 on pools []
POOL_TOO_MANY_PGS 2 pools have too many placement groups
Pool hdd has 512 placement groups, should have 128
Pool pve_cephfs_metadata has 32 placement groups, should have 4
REQUEST_SLOW 672 slow requests are blocked > 32 sec
249 ops are blocked > 2097.15 sec
284 ops are blocked > 1048.58 sec
108 ops are blocked > 524.288 sec
9 ops are blocked > 262.144 sec
22 ops are blocked > 131.072 sec
osd.9 has blocked requests > 524.288 sec
osds 0,2,6,68 have blocked requests > 1048.58 sec
osd.3 has blocked requests > 2097.15 sec
REQUEST_STUCK 4752 stuck requests are blocked > 4096 sec
1431 ops are blocked > 67108.9 sec
513 ops are blocked > 33554.4 sec
909 ops are blocked > 16777.2 sec
1809 ops are blocked > 8388.61 sec
90 ops are blocked > 4194.3 sec
osd.63 has stuck requests > 67108.9 sec
My interpretation is that Ceph
a) is busy with remapping PGs of pool hdb_backup
b) has identified several OSDs with either blocked or stuck requests.
Any of these OSDs belongs to pool hdd, though.
osd.9 belongs to node A, osd.63 and osd.68 belongs to node C (there are
4 nodes serving OSD in the cluster).
I have tried to fix this issue, but it failed with
- ceph osd set noout
- restart of relevant OSD by systemctl restart ceph-osd@<id>
and finally server reboot.
I also tried to migrate the virtual disks to another pool, but this
fails, too.
There are no changes on server side, like network or disks or whatsoever.
How can I resolve this issue?
THX
Thomas
Hi,
I tried to run this command with failure:
root@ld3955:/mnt/rbd# ceph osd set-require-min-compat-client luminous
Error EPERM: cannot set require_min_compat_client to luminous: 6
connected client(s) look like jewel (missing 0xa00000000200000); 19
connected client(s) look like jewel (missing 0x800000000000000); 23
connected client(s) look like jewel (missing 0x800000000000000); add
--yes-i-really-mean-it to do it anyway
root@ld3955:/mnt/rbd# ceph features
{
"mon": [
{
"features": "0x3ffddff8ffacffff",
"release": "luminous",
"num": 3
}
],
"mds": [
{
"features": "0x3ffddff8ffacffff",
"release": "luminous",
"num": 2
}
],
"osd": [
{
"features": "0x3ffddff8ffacffff",
"release": "luminous",
"num": 368
}
],
"client": [
{
"features": "0x40106b84a842a42",
"release": "jewel",
"num": 6
},
{
"features": "0x27018eb84aa42a52",
"release": "jewel",
"num": 19
},
{
"features": "0x27018fb86aa42ada",
"release": "jewel",
"num": 23
},
{
"features": "0x3ffddff8ffacffff",
"release": "luminous",
"num": 35
}
],
"mgr": [
{
"features": "0x3ffddff8ffacffff",
"release": "luminous",
"num": 3
}
]
}
But I think the number of clients older than Luminous is incorrect.
I'm running 98% of the clients with SLES 12SPx, and therefore the
question is:
Can you confirm in which SLES 12 release the function upmap is supported?
And is it safe to execute ceph osd set-require-min-compat-client
luminous --yes-i-really-mean-it? What happens to the clients then?
Regards
Thomas
The worst part about the official repository is that it lacks Debian
packages
Also of course it would be very convenient to be able to install any
version from the repos, not just the latest one. It's certainly possible
with debian repos...
Have just noticed their is packages available for 14.2.4..
I know with the whole 14.2.3 release and the notes not going out to a good day or so later.. but this is not long after the 14.2.3 release..?
Was this release even meant to have come out? Makes it difficult for people installing a new node if they can't reply on the current "stable" packages that apt/yum will give them.
