Search results

So we have the situation I label before with "if yes:" - next step would be to verify if ip_forwarding (/proc/sys/net/ipv4/ip_forward) is properly set to 1. If so you should see the packet sent to <internal_ip> destination port 22 at the respective bridge port (canbe also checked by tcpdump).

Es bleibt IMO nur, Komponente für Komponente auszutauschen bzw. zu entfernen wie z.B. oben beschrieben, alles andere ist pure Spekulation. Alles zu entfernen, was man nicht unbedingt braucht und dann von extern booten wäre der erste Schritt, wenn das stabil funktioniert, dann Schritt für Schritt...

Aus dem Text geht für mich nicht eindeutig hervoer, on nur WEB-access nicht mehr geht, oder auch die Konsole (direkt, nicht über ssh). Vermute Letzteres, was auf ein Hardware Problem (am ehesten Disk) hindeuted. Würde probieren mal von einem externen Laufwerk (USB) zu booten und die eingbaute...

First: check via iptables-save the currently active rules. If everything is ok - second: run the `ssh` or `telnet`command (as you already mentioned) and check via tcpdump -eni vmbr0 port 3303 whether the packets arrive properly. If yes: check whether ip_forwarding is set properly and if...

A similar request (in this case it was for bind mounts in containers) had been made already a couple of years ago, see https://bugzilla.proxmox.com/show_bug.cgi?id=1007 - feel free to add your point of view there or to open a new case.

AFAICS (not quite sure, would need the complete configuration, e.g. by a "pvereport" so see it) you use the LUN directly as disk for VM. In this case a snapshot is not possible (physical disks cannot be snapshotted, see also overview...

Da kommt mir estwas wie ein Widerspruch vor (oder ich verstehe etwas falsch): Im Prinzip ist Proxmox-Host für die Pakete nur ja nur wie ein switch (=bridge), warum also Port-Forwarding auf dem Host? Das entscheidenede ist ja die VM. auf der der Tunnel-Endpoint liegt, und die kommuniziert ja...

Assuming this is from inside Ubuntu I guess the majority of the (virtual, but seen inside Ubuntu as physical) disk is used as lvm-group. "Used" means occupied by files as the filesystem on it reports. Quite correct: ~ 1TB defiened virtual disk size But only 299GB space of physical disk (seen...

That means unfortunately Debian's driver does not support this card. You may contact the card manufacturer and check if there driver exists for Debian or if it's possible to build your own driver. Probably the more convenient approach is to by antother WiFi card (costs less tnan 20$).

What I would do: - create a new "Mountpoint" disk for the container (same size as original disk) - connect both VM (original) disk and container (new) disk as loop device (via losetup) to Proxmox host. Important that neither container nor VM must run! - let's say VM disk is now /dev/loop1 and...

- Rather not, but since I do not know details about you VM disk I cannot say for sure. Note that partition table type "loop" means "no partition table exists". In other words: In case of filesystem on disk - without partition table (which is identical to partition table "loop") data for...

AFAIU you want to pass through the (one and only) integrated graphic to a VM - that's not possible.

That's not normal, most probably that the server "hung" during those periods. Recommend to have a look into syslog in order to see what happened that time.

WiFi driver iwlwifi cannot be loaded. Possibly a kernel, firmware, driver or hardware issue repectively a combination of them. As I next step I would try to check the situation when using plain Debian11 - if it works then try to install Proxmox on top of it. If not try other Distributions as...

Check via lspci --nnk whether proper kernel module is loaded. Check also the journal, find relevant messages e.g. by journalctl | grep -i "wireless\|wifi"

Not only this - for containers it's expected that there is no partition table at all, i.e. seen with a partition tool as partition-table type "loop" Not necessary to copy file by file, you can copy the whole partition using e.g. `dd`, but - according to the above - only the partition itself and...

Since I do not know exactly how the VM are configured (for a comprehensive overview a `pvereport` would help) I can only guess: The MAC addresses from the virtual NICs inside the VMs are not accepted by the provider's switch and therefore VMs cannot communicate with the internet directly. Check...

Difficult to say. Note that as CT mount point a virtual disk must be specified which contains exactly 1 partition with filesystem ext4 on it. Maybe the disk when used in the VM was partitioned differently. In such a case as described I would rather use the GUI method for detaching the disk from...

There is obviously an error at your system disk /dev/sda where the virtual disk of vm100 is located. In a similar case I solved it recently as follows: - install a new disk with same site - boot the system with another media (e.g. live Linux system) - run `dd` for the whole disk /dev/sda to the...

As soon as a smb share is used as Storage it MUST have the respective directory corresponding to the configured content type. What not should happen is that the directories are at the mount point directory itself, i.e. the subdirectories visible also when the share is not mounted. This happens...