Cannot stop OSD in WebUI

[cmonty14]

Hi,
I want to stop several OSDs to start node maintenance.
However, I get an error message indicating a communication error. Please check the attached screenshot for details.

Please note that I have defined different storage types (NVME, HDD, etc.) in the crush map in order to use different rule sets.

Which hostname must be defined in /etc/hosts of each cluster node to ensure working WebUI for Ceph maintenance?

THX

 

[sb-jw]

Why not using the Shell to stop the OSD?!

 

[Alwin]

Which hostname must be defined in /etc/hosts of each cluster node to ensure working WebUI for Ceph maintenance?

The node with the name 'ld5507-hdd_strgbox' doesn't exist and Proxmox wants to redirect the command to the host in question. Using Ceph tools directly is your best option.

 

[cmonty14]

The node with the name 'ld5507-hdd_strgbox' doesn't exist and Proxmox wants to redirect the command to the host in question. Using Ceph tools directly is your best option.

You mean CLI?

 

[Alwin]

You mean CLI?

Yes.

 

[cmonty14]

Hm... if the function of the available button(s) is not working, I would call this a bug.
Using the CLI helps to complete the demanded task, but it's not a solution for the issue with the WebUI.

If you need more info or data to solve this issue please advise and I will try to provide it.

THX

 

[Alwin]

Hm... if the function of the available button(s) is not working, I would call this a bug.
Using the CLI helps to complete the demanded task, but it's not a solution for the issue with the WebUI.

This is not working as the name 'ld5507-hdd_strgbox' does not exist as a hostname. The commands need to be redirected to the corresponding host to work. This behavior does not trigger if device classes are used, as there will be no virtual hostnames in the crushmap.

 

[cmonty14]

I added ld5507-hdd_strgbox to /etc/hosts, but this does not solve the issue.
The error message is different, though.

 

[Alwin]

But it is not in PVE, the pveproxy needs to redirect the commands to a known PVE node.

 

[cmonty14]

Well, this means the Crush Map is incorrect.
But how should I reflect the different types for a drive (NVME, SSD, HDD) in order to use relevant rules?

 

[Alwin]

Well, this means the Crush Map is incorrect.

The crush map is a logical abstraction of the data placement and may very well not be bound to physical object. As an example, you place failure domains (racks, rooms, UPS, ...) in there to distribute the data accordingly and when disaster strikes, the data is still available.

But how should I reflect the different types for a drive (NVME, SSD, HDD) in order to use relevant rules?

Ceph allows to use the device classes for this (eg. NVMe, SSD, HDD). You can also define custom device classes, eg. strgbox. See our docs for the configuration.
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_device_classes

 

[cmonty14]

Hi,
I'm aware of the object classes. As far as I understand Ceph can now identify the object class of a disk automatically.

My intention was this:
In order to ensure that a VM uses a specific disk say NVME, I need to
- define another root nvme
- define a fake hostname, e.g. <hostname>-nvme
- set the OSD to the new root and hostname:
ceph osd crush set <osd.id> <weight> root=nvme host=<hostname>-nvme
- define a rule

Is this procedure obsolete?
If yes, how can I ensure that a VM uses a specific disk?

THX

 

[Alwin]

As far as I understand Ceph can now identify the object class of a disk automatically.

Yes it can, but you can also define your own, if needed.

Is this procedure obsolete?

Kinda, you can still do it this way, it just makes more work and in bigger ceph clusters it gets harder to manage.

If yes, how can I ensure that a VM uses a specific disk?

The VM itself isn't aware of a OSD. The pool, where the VM has its image(s), is configured to use the specified crush rule and all data written to that pool will be placed according to it.