Search results

The first thing that comes to mind is to use a somewhat simple password which has no means of being somewhat mangled, if the input while installing is other as when the system boots up. Let's say use 123456 or something similar simple to ensure that you can get into the recevory shell, when...

Okay, then I have misinterpreted the situation, since I had only your screenshot to look at. Would you care to describe you problem in english then? I take from your latest post, that you tried to install PVE and after installation your install doesn't boot successfully, is that correct?

I am sorry, but I don't speak spanish, please use english.

A message like this almost always point to some storage-based issue. You will need to have the pve host's root password to get in and see/fix what is broken. If you don't have the root password you can try to boot into emergency mode and see, if you can see what's wrong there.

Yeah… obviously, but… I still wonder what causes the issue with the monitor. root is on ZFS and the volume comes back clean and I don't see a reason why the monitor shouldn't get back up and running.

I am quite curious… I experienced some HW issues (well, presumeably) on one of my Ceph nodes in my 3-node Ceph cluster. Everytime I rebootet the host, which then had been hung for some length of time, the Ceph mon on this host would be dysfunctional and I needed to re-setup the monitor. Is this...

Actually, I'd cut that short and use a config like this: auto lo iface lo inet loopback auto enp2s0 iface enp2s0 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.178.131 netmask 255.255.0.0 gateway 192.168.0.1 bridge_ports enp2s0 bridge_stp off bridge_fd...

So, the "outside" network is 192.168.0.0/16 and the routed one shall be 192.168.25.0/24 and you're performing NAT from the "inner" network, which is actually enclosed in the "outer" network? What's the point of doing that? Since all the traffic is passing through the physical interface anyway...

Your vmbr0 has no interface assigned, so all the guests can only communicate among themselves. You can regard the term bridge literally here. As I said before, assign your host IP to the bridge and the interface to the list of bridge_ports of vmbr0.

You can setup your OSDs the way you want and then would have to manage the volumes on those OSDs accordingly. You will not get two clusters, but a cluster with two volumes. If you really wanted another cluster, then you'd have to throw in more hosts.

Always attach the IP address to the bridge - not to the physical interface and move the interface into the vmbr0.

Really? You first created a LVM on /dev/sdb and then afterwards formatted it as ext4? If you created a LVM volume you'd need to format the LV with ext4, not the partiton, this is bound to go wrong. I'd assumed something like mkfs.ext4 /dev/<VG>/<LV> instead of /dev/sdb1

What about first lining up your setup and then let us see, how can get you to achieve, what you want?

You might be able to reduce your lvs, but that would depend also on the file system used inside the VM. Also… if think about re-installing the server, make sure, that you backup your VM first.

Actually, either of them can, and will contribute to this issue. As do snapshots (LVM-wise and VM-wise). As the warning stated, you have provisioned 8GB more space, than you actually have. Also, LVM is COW (copy-on-write) which will always first write new data to the volume and then...

There are some good threads about how to tackle the swap issue - just use the forum search.

Despite that's a bit surprising, that you having such issues with proxmox, the answer depends a bit on how you installed proxmox. Did you use the PVE install, or did you install proxmox on top of another base disto, e.g. Debian, Ubuntu… And before pulling the trigger on proxmox… did you ask...

Okay… let's start with a basic layout and try to tackle one thing at a time. As you pointed out, you do have currently these storage devices: 2x 128GB SSD 3 x 4TB HDD You setup a ZPOOL from the two SSDs and installed PVE on it. I assume. that you then installed FreeNA in a VM on the local...

I still don't get, what you are trying to achieve. You can share a ZFS from your ZPOOL out via NFS, no problem with that. Any VM that has it's virtual drives be located on the very same ZPOOL will create a ZVOL(s) within the root ZFS, which will nibble space away from your NFS share. Please...

These warning are actually quite worrysome, since you have over-provisioned your volume group. That is, you have created thin volumes, which only take as much physical space in your volume groups as they actually have initially, but once they rise to their full usage they will try to occupy more...