Recent content by sry

Nochmal Danke :) Klingt nach nem guten Weg, dürfte aber auch einiges an config auf dem PVE-Server erfordern. Zwischenzeitlich wurde mir ein 4. Weg vorgeschlagen: 1 OPNsense auf Hetzner Cloud VM, eine 2. auf dem Proxmox, beide via VPN verbunden. Die 1. OPNsense ist dann komplett für die...

Nachtrag: Anstatt mit vlan/cloud lan könnte die Firewall/Proxy VM in der Hetzner Cloud per VPN mit einer "VPN-VM" in PVE-LAN verbunden werden - dann müsste außer vmbr0 für Lan auf dem Proxmox AFAIK nichts eingerichtet werden. Recovery steps für PVE wären dann: - neu aufsetzen - vmbr0...

Also, ein dedicated Hetzner server mit dessen public ip als Firewall vor das ganze setzen? Ist unwirtschaflich, für den müsste dann zusätzlich ein disaster recovery vorbereitet werden. Ein Hetzner Cloud Server als FW wäre zwar günstiger und DR wäre über Snapshot-Backup easy, aber dann muss cloud...

Danke für das Feedback - grundsätzlich habe ich kein Problem mit conf-files und bash, und ich weiß auch auch so halbwegs, was ich tun möchte ;) Mir geht es darum, ein maximal übersichtliches disaster recovery zu ermöglichen. Sprich, ich will nicht aus dem Urlaub geklingelt werden, falls PVE...

Hallo zusammen, eigentlich kein exotisches Szenario: Hetzner Server mit 1 phys NIC, PVE ist installiert. Es sollen ein paar LAMP VMs darauf laufen. Diese sollen abgehende Verbindungen zum Internet aufbauen können und aus dem Interenet erreichbar sein (https/ws, 443/8090). Grober Ansatz...

It died at times when backups ran, but this is at night and I can only roughly estimate when exactly the VM dies as it seems to lose last log info, too. But, it died also when I moved the storage of another VM (which is I/O intense, of course). I realized that after a few seconds, it is likely...

The VM is completely dead in those situations, no reaction on ping, no ssh possible, no vnc in browser console, no reaction in GUI on shutdown/reboot/... dropdown menu. Only thing that worked for me was qm stop and then qm start from console of the node. After VM is up then, it runs without any...

Update + new findings Moved the storage of the critical VM to the new SSD (had it shut down to be on the safe side). Changed nothing else, and - backup duration (dump) is same as before. But the additional Backup I do on external NAS (with SATA Disk, too, 1GB NIC) is much faster now (takes half...

The errors were failures mounting volumes. I didn't dig deeper into this but also suspected rather probs with the clone itself than with the adoptions on controller side. Next step will be to move the VM to the new SSD Storage. Then I have to take a final decision whether I go for 1 PVE node +...

Update: Yesterday I cloned the Suse VM, updated node to 7.3, changed clone from VirtIO to VirtIO single + did the other settings >> starts with filesystem errors. Reverted to VirtIO (kept new settings assuming they work only with VirtIO single which I now know is wrong) >> errors kept...

1st of all - THX for all your efforts! @_gabriel: your English seems immaculate to me (maybe I don't see the mistakes because I'm German ;) ) PBS? - hmmm. Maybe I better describe the environment more in detail: Have 3 HP Proliant DL320 G6 with 32G RAM each, old but in good condition. 2 of...

Backup with vzdump, compression already disabled (helped a bit) but open for alternative, is ok if backzp takes some time as a separate application dump is done before backing up VM. Will check writecache settings during holidays. I know, HW is ancient, but I like the idea using it as long as...

4 x Intel(R) Xeon(R) CPU E5603 @ 1.60GHz (1 Socket) and, maybe of interest: HDD = WesternDigital WD Ultrastar DC HC320 Controller: HP Smart Array B110i

Hello, after a period of testing we are about to go productive with PVE. But, for budget- and capacity reasons we have to store backups/snapshots on conventional SATA-HDDs. We also can see I/O issues that cause high CPU loads similar to those posted, for example...

Danke, aber das setzt Docker voraus - da wollte ich mich noch eine Weile vor drücken ;)