Recent content by omgs

Hi. I have an i7 motherboard with 32 GB RAM running proxmox 8.x with debian bookworm. It plays mostly nice, but when installing (I.e. using apt) packages, I find it too slow. I find that it takes very few resources. I have about 10 lxc containers (all using bookworm) and usually assing at least...

I'd like (as long as it's free ;)) to have the whole PBS. I have plans for remote secondary (or more replicas) pbs installations in raspberry pi or similar boxes (or course, with an external disk attached).

A little trick I use to manage situations mounting unprivileged containers on the host, I create a host user (ang group) called lxc-root with id 100000. The same principle stands for lxc-www-data. From within the guest, sometimes you can't chown files inside the container because of the uid, and...

Ok, thanks for your reply.

Hi. I open a new thread following with my homemade cluster lab. I already have 3 nodes under virtualbox. The main node has a raw local disk and acts as iscsi server for that target, so its purpose is to have that shared storage for all nodes using the same target for all nodes and use the iscsi...

Ok, I've given up that option. Thanks.

I understand what you mean. But I wonder, what's the proper use of the device passtrough option in containers?

Hi. I'm creating a test lab where I intend to have a privileged (or unprivileged if possible) lxc container. This ct uses tgtd for sharing iscsi luns to other hosts in the bridge. So, in the proxmox host, I have an unused raw disk (/dev/sdb, with an unformatted partition sdb1) whose only...

The syntax starting with <code>mpX</code> is for mount points. The <code>lxc.mount.entry</code> and the <code>mpX: /..... </code> are equivalent.

Ok, it looks like when there are aborted backups, prune is necessary though there isn't associated backup. I guess that prune "marks" unassociated chunks as to be deleted, and if gc can't find such mark, won't delete that chunk, even if gc finds it unassociated. In my installations, prune takes...

Apart from basic connection, I meant the if the port is open for connection. Did you check that?

Is there a typo? /dev/sdb isn't a filesystem. Any way, you have to umount or run in single mode to check the filesystem.

Since it's a network connection, check the firewall. Then, the most common reason for "weird errors" like that is an error in the filesystem. Check with fsck for errors.

I might be wrong, but I guess that since there's no associated backup, the theorical prune is already done, so manually running the garbage collection job should clean up the unused chunks. Is this assumption right?

What I mean is that, as long as the underlying filesystem where the datastore resides has no issues, I think you don't need to reverify. The time you find out there's a problem with the filesystem, after repairing, you may need to check everything, regardless the source where it came from.