Search results

I've used POM to install Ceph Reef + PVE updates on a fully offline cluster. Just add the appropriate repos to POM, run the mirroring process and change the system repos to point to your POM. Sadly the clien't did not want suscription for that cluster, so I can't tell experience on how POM works...

Glad you found it. Had a half written post suggesting you to check pvedaemon systemd unit, as any process started by a systemd service inherits the environment of the service itself + any other envars set when starting the process. Here is where pvedaemon could read a setting from datacenter.cfg...

It does not. At least not under every circumstance. There's zero guarantee that you will get that second copy done to any OSD: if the primary OSD fails/breaks/can't reach/whatever and/or the secondary OSD is unable to write the data and before that second copy is done your primary OSD fails, you...

Hibernating the VM isn't best practices, which recommend either migrate the VM to other host of the cluster or full shutting them down and start again (besides having backups, etc which isn't relevant in this case). I can confirm that you can install updated packages with running VMs without...

That would be a let down. This should be easily adjusted i.e. at datacenter.cfg so a normal restore from the web UI applies them (i.e. non root user(s) with enough privileges to restore their VMs). I would be ok if you had to use cli to set those values, although IMO they should be available in...

PVE will let you choose ZFS even if you have raid, but you will be running a fully unsupported configuration and when issues arise no one will be able to/willing to provide support. Check your hardware: many SmartArray allow to either change their personality to JBOD / IT / Passthrough mode or...

Besides what you've been already recommended (specially related to the technological debt), I would like to mention that snapshot and thin provisioning for shared iSCSI/FC LVM is in the works and expected to come with PVE9.x

Don't know what you are referring to. You simply get the hosts to a set of switches, configure L2 connectivity (bonds, vlans, trunks, etc) and configure a bridge in each PVE connected to the appropriate hosts nic(s). VMs will be able to communicate with each other even on different hosts. You...

Of course, because even if the cert comes from a verifiable CA, it's CN does not contain the IP. It's the same as if you were accessing your PBS using a different host name. Yes, it will. That's what you setup a caddy for, isn't it? To get it to proxy request and provide automatic SSL cert...

You've end up with a non standard PVE, configured in a "non-pve way of doing things", with issues that wouldn't happen if you followed the manual/best practices (PVE ACL, permissions, too many bridges). Glad it works for you, but remember the way you did all this when asking for support ;)

Can't really tell what's going on. There might be that tunnel interfering with some traffic, might be firewall rules, might be some issue related to the certificate... Basic network connectivity looks fine, services are up, seems that they reach each other because that shell part seems to...

It is not: the storage used at the PVE host doesn't matter at the VM OS level. And if it is it would be the first time I see something like that... You probably did something different with that VM besides storing it in local-lvm. If that VM boots correctly, move it now to your iSCSI storage...

Bridges are the "virtual switch" that a VM/CT needs to connect to a network. Simply do not create bridges for any internal network that no VM should have access to, just use the interface/bond/vlan at host level.

Sorry, pasted the wrong command. The right one is: wget --no-check-certificate -qO - https://$HOSTNAME:8006 | grep 'Proxmox Virtual Environment' 2> /dev/null So the two nodes are in different locations at 250ms apart? That is an issue that will cause pmxcfs to fail eventually. Check...

Missing the output of these commands in both nodes: wget --no-check-certificate -qO - https://$HOSTNAME:8006 | grep 'Proxmox Virtual Environment' 2> /dev/null systemctl status pveproxy Calls my attention that your corosync is using IPv6 instead of IPv4, although it's completely unrelated to...

It isn't 100% safe to run a repair, but in your case is quite near to that 100% as it looks you have 2 healthy replicas. Make backups of everything and try to repair. I would suspect on that OSD.3 as it appears in all 3 inconsistent errors you have. Check logs and even rebuild from scratch, as...

Post this info of both hosts in CODE tags: Of both hosts: cat /etc/hosts pvecm status corosync-cfgtool -s ip addr wget --no-check-certificate -qO - https://$HOSTNAME:8006 | grep 'Proxmox Virtual Environment' 2> /dev/null cat /etc/pve/.members

We both gave the exact same response, even for CODE tags ;)

You picked "mirror" instead of RAIDz and now you have a ZFS mirror with 8 copies :) Please, please! Use CODE tags to post command output, it very hard to read otherwise:

The correct step is to analyze why it is out of quorum by checking the logs (/var/log/ceph/ceph-mon*) of that MON and the other two when you restart the mon at pve-02. From there, you will probably get clues about what's going on, if it can be fixed, etc. You should be able to remove it and...