Het grote Proxmox VE topic

[icecreamfarmer]

CurlyMo schreef op vrijdag 18 juni 2021 @ 17:11:
[...]

Tsja, een beetje moeite doen. Complex is deze specifieke aanpassing niet.

Nah beetje moeite het kost me nu al maanden om dit werkend te krijgen. USB passthrough met LXC zou ook zo gedaan moeten zijn. Werkt ook nog steeds niet.

Maar waarom zou het met deze mountpoints wel werken?

[CurlyMo]

icecreamfarmer schreef op vrijdag 18 juni 2021 @ 17:13:
[...]


Nah beetje moeite het kost me nu al maanden om dit werkend te krijgen. USB passthrough met LXC zou ook zo gedaan moeten zijn. Werkt ook nog steeds niet.

Maar waarom zou het met deze mountpoints wel werken?

Omdat USB passthrough een stuk complexer is dan dit

Dit verteld Proxmox dat er in de kern alternatieve paden zijn om gegevens op te slaan. Dat is anders dan lapmiddelen achteraf.

[icecreamfarmer]

CurlyMo schreef op vrijdag 18 juni 2021 @ 17:14:
[...]

Omdat USB passthrough een stuk complexer is dan dit

Dit verteld Proxmox dat er in de kern alternatieve paden zijn om gegevens op te slaan. Dat is anders dan lapmiddelen achteraf.

Die snap ik niet. Dan slaat hij tijdelijk de bestanden ergens anders op?

Overigens doet de hdd niet aan spin down.

[CurlyMo]

icecreamfarmer schreef op vrijdag 18 juni 2021 @ 18:45:
[...]


Die snap ik niet. Dan slaat hij tijdelijk de bestanden ergens anders op?

Overigens doet de hdd niet aan spin down.

Nee, permanent.

Zo staan in mijn geval al mijn vm's dus standaard op /data/vm/:

# zfs list -o name -r data/vm
data/vm
data/vm/subvol-100-disk-0
data/vm/subvol-101-disk-0
data/vm/subvol-102-disk-0
data/vm/subvol-102-disk-1
data/vm/subvol-103-disk-0
data/vm/subvol-104-disk-0
data/vm/subvol-105-disk-0
data/vm/subvol-106-disk-0
data/vm/subvol-107-disk-0
data/vm/subvol-108-disk-0
data/vm/subvol-109-disk-0
data/vm/subvol-114-disk-0
data/vm/subvol-119-disk-0
data/vm/vm-110-disk-0
data/vm/vm-111-disk-0
data/vm/vm-113-disk-1
data/vm/vm-115-disk-0

[ Voor 52% gewijzigd door CurlyMo op 18-06-2021 20:38 ]

[powerboat]

icecreamfarmer schreef op vrijdag 18 juni 2021 @ 14:20:
Heeft iemand hier een usb drive as hoofdopslag voor VM's en dergelijke werkend gekregen.
Ik kan een ZFS en/of Directory aan maken maar het moment dat ik hem toewijs aan een VM gaat het fout.
In het begin werkt alles maar na een tijdje disconnect hij.

Bij Directory krijg ik dan deze foutmelding:

TASK ERROR: unable to activate storage 'USBHDD' - directory is expected to be a mount point but is not mounted: '/mnt/pve/USBHDD'


Dit terwijl hij de disk wel blijft zien en ik ook smart data kan ophalen. Rechtstreekse passthrough als usb device werkt wel probleemloos.

Iemand ideeen?

mijn ervaring om vm'tjes van usb storage is niet erg goed. Zou het eerlijk gezegd ook niet aanraden.

[CurlyMo]

powerboat schreef op vrijdag 18 juni 2021 @ 21:23:
[...]


mijn ervaring om vm'tjes van usb storage is niet erg goed. Zou het eerlijk gezegd ook niet aanraden.

Zonder de specifieke situatie te kennen lastig om over te oordelen. Wie weet staat er wel een specifieke backup VM op de backup schijf, die periodiek start. Dan kan ik me er iets bij voorstellen. Anders zou ik ook niet van een externe schijf afhankelijk willen zijn.

[icecreamfarmer]

CurlyMo schreef op vrijdag 18 juni 2021 @ 19:16:
[...]

Nee, permanent.

Zo staan in mijn geval al mijn vm's dus standaard op /data/vm/:

# zfs list -o name -r data/vm
data/vm
data/vm/subvol-100-disk-0
data/vm/subvol-101-disk-0
data/vm/subvol-102-disk-0
data/vm/subvol-102-disk-1
data/vm/subvol-103-disk-0
data/vm/subvol-104-disk-0
data/vm/subvol-105-disk-0
data/vm/subvol-106-disk-0
data/vm/subvol-107-disk-0
data/vm/subvol-108-disk-0
data/vm/subvol-109-disk-0
data/vm/subvol-114-disk-0
data/vm/subvol-119-disk-0
data/vm/vm-110-disk-0
data/vm/vm-111-disk-0
data/vm/vm-113-disk-1
data/vm/vm-115-disk-0

Ik zie nu dat mijn uitleg niet duidelijk was.
Mijn vm 's staan gewoon op de interne ssd, dat werkt wel.

De externe harde schijf is voor de data van de openmediavault vm. Ik wilde dat als lcx doen maar dan moet proxmox de storage regelen. Dat werkt echter niet omdat de disk lijkt te unmounten na een tijdje.

[mdbraber]

Over Proxmox backups. Ik heb op mijn hypervisor een SSD met een rpool waar al mijn VMs op draaien. In één van die VMs draait al mijn storage met disks als passthrough (2x 1TB SSD apart en 4x 5TB HDD als raid10). Alle disks maken gebruik van ZFS.

Wat is de beste manier om backups te maken van mijn Proxmox VMs? Ik kan in mijn 'storage VM' bijv. Proxmox Backup Server of Syncoid gebruiken en dan de Proxmox backups via de storage VM op de ZFS pool van een van de andere SSDs of HDDs plaatsen. Mocht er iets met Proxmox gebeuren dan zou ik gewoon de zpool van die disk(s) ook zonder de VM moeten kunnen benaderen. Bij voorkeur wil ik de SSDs niet direct aan de hypervisor / Proxmox hangen, omdat ik het liefst de storage (grotendeels) in de VM gebruik (backup is maar een klein deel). Theoretisch zou ik 'm met partities kunnen splitsen, maar dat heeft met ZFS niet de voorkeur (liever whole disk devices). Een extra backup disk is eigenlijk geen optie, omdat alle SATA aansluitingen inmiddels al vol zitten (of het zou over USB3 moeten).

Wat zouden jullie aanbevelen voor het maken van backups? Gewoon naar de passhtrough disk in de VM of een andere oplossing?

[ Voor 12% gewijzigd door mdbraber op 22-06-2021 13:42 ]

[Theone098]

mdbraber schreef op dinsdag 22 juni 2021 @ 12:35:
Over Proxmox backups.

[...]

Wat zouden jullie aanbevelen voor het maken van backups? Gewoon naar de passhtrough disk in de VM of een andere oplossing?

Ik maak gebruik van de Proxmox backup mogelijkheid. De backup zelf sla ik op op het NAS (die als storage gemount is aan de proxmox server(s)). Ik maak altijd full backups (images eigenlijk, met stop) en ik bewaar de laatste 2.

Van de directory op het NAS wordt weer een backup gemaakt naar een ander NAS.

[ Voor 30% gewijzigd door Theone098 op 23-06-2021 16:27 ]

[ntiender]

Ik heb een servertje draaien met proxmox waar diverse VM's op staan.
Hier draait o.a. een VM voor domotica en netwerk op.

Nu wil ik in de woonkamer een touchscreen gaan plaatsen met mogelijk een ingebouwde PC.
Kan ik deze gebruiken voor redundantie? Door hier dan ook proxmox op te laten draaien die automatisch de taken overneemt als de server uitvalt?

Kan ik de video-uitvoer dan gemakkelijk doorzetten naar een extra VM voor het touchscreen?

Hardware is niet hetzelfde!

Of gaat dit niet werken? Dan kan ik gewoon een simpelere(goedkopere) touch-screen kopen met een PI

[Theone098]

ntiender schreef op donderdag 24 juni 2021 @ 15:08:
Ik heb een servertje draaien met proxmox waar diverse VM's op staan.
Hier draait o.a. een VM voor domotica en netwerk op.

Nu wil ik in de woonkamer een touchscreen gaan plaatsen met mogelijk een ingebouwde PC.
Kan ik deze gebruiken voor redundantie? Door hier dan ook proxmox op te laten draaien die automatisch de taken overneemt als de server uitvalt?

Kan ik de video-uitvoer dan gemakkelijk doorzetten naar een extra VM voor het touchscreen?

Hardware is niet hetzelfde!

Of gaat dit niet werken? Dan kan ik gewoon een simpelere(goedkopere) touch-screen kopen met een PI

Je hoeft voor proxmox niet dezelfde server hardware te gebruiken. Je hebt wel shared storage nodig om de VM van de ene naar de andere server (node) te verplaatsen (een NAS bijvoorbeeld). De VM moet wel dezelfde configuratie hebben, denk ik. Anders is zeker een reboot nodig van de VM.

Ik heb dit alweer een poos geleden gedaan (versie 4 denk ik) en het weer uitgezet. Ik weet niet of er in de tussentijd veel is veranderd in Proxmox.

[unezra]

mdbraber schreef op dinsdag 22 juni 2021 @ 12:35:
Over Proxmox backups. Ik heb op mijn hypervisor een SSD met een rpool waar al mijn VMs op draaien. In één van die VMs draait al mijn storage met disks als passthrough (2x 1TB SSD apart en 4x 5TB HDD als raid10). Alle disks maken gebruik van ZFS.

Wat is de beste manier om backups te maken van mijn Proxmox VMs? Ik kan in mijn 'storage VM' bijv. Proxmox Backup Server of Syncoid gebruiken en dan de Proxmox backups via de storage VM op de ZFS pool van een van de andere SSDs of HDDs plaatsen. Mocht er iets met Proxmox gebeuren dan zou ik gewoon de zpool van die disk(s) ook zonder de VM moeten kunnen benaderen. Bij voorkeur wil ik de SSDs niet direct aan de hypervisor / Proxmox hangen, omdat ik het liefst de storage (grotendeels) in de VM gebruik (backup is maar een klein deel). Theoretisch zou ik 'm met partities kunnen splitsen, maar dat heeft met ZFS niet de voorkeur (liever whole disk devices). Een extra backup disk is eigenlijk geen optie, omdat alle SATA aansluitingen inmiddels al vol zitten (of het zou over USB3 moeten).

Wat zouden jullie aanbevelen voor het maken van backups? Gewoon naar de passhtrough disk in de VM of een andere oplossing?

Je kunt kijken naar de nieuwe Proxmox Backup Server.

Zelf gebruik ik al een tijdje Sanoid/Syncoid naar een externe machine. (Colocatie, dus werkelijk fysiek gescheiden van mijn server thuis.)

https://github.com/jimsalterjrs/sanoid

[wilbert11]

Proxmox 7.0-beta is vandaag gereleased. Heb hem op m'n NUC11 geïnstalleerd en tot nu toe geen problemen ;-)

[cville]

Ik redirect op dit moment alle log files naar een aparte pool: lpool. Het valt me op dat zodra ik op het Proxmox dashboard inlog, de write rate van 2.4 naar 10.4 GB/dag toeneemt; een toename van 8GB/dag. Heeft iemand hier een verklaring voor?

[zeroday]

Klein probleempje .
ik wil meer backups met pbs bewaren, maar er wordt altijd maar 7 dagen bewaard

Nu heb ik de
https://pbs.proxmox.com/docs/prune-simulator/index.html

gevonden en zie ook mijn issue

de Number of weeks wat in deze simulator zit, zie ik nergens en dat moet ik bijv. op 4 weken zetten om ook een week / maand backup te krijgen

Waar kan ik die number of weeks vinden?
ik zie het niet in de proxmox node config bij Backup waar ik de de tijd en dagen definieer

[Possible]

Vraagje,

Ik heb een USB to RS485 adapter gekocht om een Kwh meter in de meterkast uit te lezen. Nu heb ik de usb stick toegewezen aan een VM waar home-assistant op draait. Vervolgens in de VM van home-assistant in node-red een flow gemaakt om die kwh meter uit te lezen (via mqtt -> home-assistant)

Nu zie ik geen data binnenkomen in home-assistant.

ALs ik vervolgens een losse raspberry pi pak en deze aansluit dan werkt het wel. Dus het gaat mis met de communicatie van proxmox naar de vm


De USB stick adapter wordt in proxmox netjes herkend, Ik heb deze ook toegewezen als ''Use USB Port"" en daar de stick opgegeven.


Wat kan het zijn dat het niet werkt ?

@CurlyMo
Toevallig zie ik je hier… de kWh meter is voor de pana .. gebruik jij dat ook icm met home assistant?

[ Voor 8% gewijzigd door Possible op 01-07-2021 23:16 ]

[CurlyMo]

Possible schreef op donderdag 1 juli 2021 @ 22:56:
@CurlyMo
Toevallig zie ik je hier… de kWh meter is voor de pana .. gebruik jij dat ook icm met home assistant?

Nee, ik zat hier overigens al een tijdje

Overigens heb ik mijn kWh meters aan de Heishamon gekoppeld die gewoon de waardes uitspuugt via MQTT.

[ Voor 16% gewijzigd door CurlyMo op 01-07-2021 23:24 ]

[Possible]

CurlyMo schreef op donderdag 1 juli 2021 @ 23:18:
[...]

Nee, ik zat hier overigens al een tijdje

Overigens heb ik mijn kWh meters aan de Heishamon gekoppeld die gewoon de waardes uitspuugt via MQTT.

Oke

Maar heb je ook enig idee waar het probleem in zit ?

[krijn1985]

Possible schreef op donderdag 1 juli 2021 @ 22:56:
Vraagje,

Ik heb een USB to RS485 adapter gekocht om een Kwh meter in de meterkast uit te lezen. Nu heb ik de usb stick toegewezen aan een VM waar home-assistant op draait. Vervolgens in de VM van home-assistant in node-red een flow gemaakt om die kwh meter uit te lezen (via mqtt -> home-assistant)

Nu zie ik geen data binnenkomen in home-assistant.

ALs ik vervolgens een losse raspberry pi pak en deze aansluit dan werkt het wel. Dus het gaat mis met de communicatie van proxmox naar de vm


De USB stick adapter wordt in proxmox netjes herkend, Ik heb deze ook toegewezen als ''Use USB Port"" en daar de stick opgegeven.


Wat kan het zijn dat het niet werkt ?

Ik gebruik zelf de "Use USB Vendor/Device ID" optie. Heb je je VM al een keer herstart na het doorgeven? Of kijk hier even hoe je hem doorgeeft aan een draaiende VM.

Met lsusb op je proxmoxhost kun je ID (zoiets als AxBCDE:0x1234) ophalen dan via qm monitor <VMID> kom je in QEMU monitor van VM en dan met device_add usb-host,vendorid=AxBCDE,productid=0x1234 kun je hem toevoegen aan je VM.

Check ook voral even met lsusb in je VM of je hem daar ziet.

[Possible]

krijn1985 schreef op vrijdag 2 juli 2021 @ 07:41:
[...]


Ik gebruik zelf de "Use USB Vendor/Device ID" optie. Heb je je VM al een keer herstart na het doorgeven? Of kijk hier even hoe je hem doorgeeft aan een draaiende VM.

Met lsusb op je proxmoxhost kun je ID (zoiets als AxBCDE:0x1234) ophalen dan via qm monitor <VMID> kom je in QEMU monitor van VM en dan met device_add usb-host,vendorid=AxBCDE,productid=0x1234 kun je hem toevoegen aan je VM.

Check ook voral even met lsusb in je VM of je hem daar ziet.

Ik zal eens kijken of dat gaat lukken inderdaad. Omdat ik ook een P1 kabel heb, geven deze dezelfde Id's weer:



Dus dat is ook vaag.

[krijn1985]

Dat kan het wel lastig maken, ik heb hier zelf geen ervaring mee hoe Proxmox (QEMU) hiermee omgaat.

[CurlyMo]

Possible schreef op vrijdag 2 juli 2021 @ 07:40:
[...]


Oke

Maar heb je ook enig idee waar het probleem in zit ?

Heb je al eens geprobeerd je hele USB controller in passthrough te zetten mits je CPU dat ondersteund?

[Possible]

CurlyMo schreef op vrijdag 2 juli 2021 @ 07:59:
[...]

Heb je al eens geprobeerd je hele USB controller in passthrough te zetten mits je CPU dat ondersteund?

Nee nog niet geprobeerd, Zal eens zien of dat lukt. CPU is al een aantal jaartjes oud namelijk. Intel Pentium G4400 meende ik.

[CurlyMo]

Possible schreef op vrijdag 2 juli 2021 @ 08:17:
[...]


Nee nog niet geprobeerd, Zal eens zien of dat lukt. CPU is al een aantal jaartjes oud namelijk. Intel Pentium G4400 meende ik.

Ding ondersteund VT-d en VT-x dus moet lukken. Als je moederbord het dan nog ondersteund.

[wilbert11]

Ter info. Proxmox 7.0 is vandaag gereleased

[Hmmbob]

wilbert11 schreef op dinsdag 6 juli 2021 @ 16:59:
Ter info. Proxmox 7.0 is vandaag gereleased

downloads: Proxmox VE 7.0

[Zorian]

Ik krijg 7.0 niet te zien bij de updates. Zal zeker weer even duren voordat ie verschijnt.

//edit: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0 deze werkt, zit nu op 7.0.

[ Voor 33% gewijzigd door Zorian op 06-07-2021 21:51 ]

[LosserNL]

Edit: net te laat

[ Voor 87% gewijzigd door LosserNL op 06-07-2021 21:53 ]

[Zorian]

Hm, kleine waarschuwing: 1 van mijn VM's werkt niet meer na de upgrade. Hij is configured met Q35 (latest) en UEFI. Als ik hem start zie ik het Proxmox schermpje met een _ linksboven en er gebeurt niks. 0,0% CPU/RAM usage ook.
Mocht iemand een idee hebben hoe ik kan zien wat het probleem is of een tip heeft, dan graag.

//Edit: Fixed!
De oplossing voor mij was de disk deattachen en dan met dit commando hem weer reattachen:
qm set <VMID> --scsi[n] local-zfs:vm-<VMID>-disk-[n],discard=on
Even de boot order herstellen in de options en het werkt weer.

[ Voor 44% gewijzigd door Zorian op 07-07-2021 16:30 ]

[orvintax]

@Zorian Gebruik je nog een andere BIOS naast Q35 voor je VM's? Ging daar alles goed?

[Zorian]

orvintax schreef op woensdag 7 juli 2021 @ 02:56:
@Zorian Gebruik je nog een andere BIOS naast Q35 voor je VM's? Ging daar alles goed?

Alle VM's staan op q35 (latest) en UEFI (OVMF). Afgezien van het incidentje met die ene VM is alles soepeltjes gegaan.

[Feni]

Upgrade naar Proxmox 7.0 ging prima, even de tutorial volgen in de migratie wiki en je bent over.

GPU/PCIe passtrough etc blijft netjes werken. Fijn dat het dashboard nu eindelijk Gi ipv GB toont.

[joecks]

Na de upgrade doet bij mij alles het weer alleen docker in LXC start niet meer op ...
Ik kom tot de volgende logging maar ik kom er niet verder mee , iemand die mij op weg kan helpen ?

service docker start

code:

Job for docker.service failed because the control process exited with error code.
See "systemctl status docker.service" and "journalctl -xe" for details.
root@NginxPM /#

systemctl status docker.service

code:

* docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2021-07-07 06:56:16 UTC; 43s ago
     Docs: https://docs.docker.com
  Process: 741 ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS (code=exited, status=1/FAILURE)
 Main PID: 741 (code=exited, status=1/FAILURE)
      CPU: 155ms

Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Consumed 155ms CPU time.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Service RestartSec=100ms expired, scheduling restart.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
Jul 07 06:56:16 NginxPM systemd[1]: Stopped Docker Application Container Engine.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Consumed 155ms CPU time.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.

journalctl -xe

code:

-- 
-- The job identifier is 764.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.service has entered the 'failed' state with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: A start job for unit docker.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit docker.service has finished with a failure.
-- 
-- The job identifier is 713 and the job result is failed.
Jul 07 06:56:16 NginxPM systemd[1]: docker.socket: Failed with result 'service-start-limit-hit'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.socket has entered the 'failed' state with result 'service-start-limit-hit'.
Jul 07 06:56:16 NginxPM systemd[1]: docker.socket: Consumed 1ms CPU time.
-- Subject: Resources consumed by unit runtime
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.socket completed and consumed the indicated resources.
Jul 07 06:57:01 NginxPM CRON[765]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 07 06:57:01 NginxPM CRON[766]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Jul 07 06:57:01 NginxPM CRON[765]: pam_unix(cron:session): session closed for user root

[randommen]

@joecks kijk eens naar je cgroups, lxc is een container en daar is iets in veranderd geloof ik.

[RL600]

Zojuist een update gedaan en volgens de webUI zit ik nu op: 7.0-8

Ik heb een LACP bundel met 4 poorten. Deze werkte prima voor de upgrade, maar nu niet meer (op VM niveau. Switch geeft aan dat de LACP bundel actief is).

Normaal gesproken heb ik de NIC van een VM staan op een VirtIO en bij het aanpassen naar een E1000 werkt het wel weer. Ik heb op deze node drie VM's draaien (Ubuntu 20.04 (server LTS) en 2x een Linux Mint die up to date is), alle drie hebben deze hetzelfde probleem.

E1000 geeft bij een hoge CPU load en een significant lagere max. throughput. Iemand een idea hoe ik de VirtIO weer aan de praat kan krijgen?

Update: meerdere keren herstarten mocht niet baten

Update2: alle poortnamen zijn correct en komen nog steeds overeen met de LACP groep

[ Voor 9% gewijzigd door RL600 op 07-07-2021 10:00 ]

[randommen]

@RL600 misschien voor de hand liggend, maar heb je de host wel een keertje herstart na de update? Dan wordt de kernel opnieuw geladen en aangezien VirtIO paravirtualized is, is dat misschien je probleem.

[RL600]

@randommen goed punt haha! Drie keer gedaan.... geen verschil

[ Voor 20% gewijzigd door RL600 op 07-07-2021 09:56 ]

[randommen]

Is je interfacenaam misschien veranderd van de bridge die in je lacp bond zit? @RL600
Dan is je bond wel up maar heeft je bridge geen host interface.

Zou alleen niet verklaren waarom E1000 wel werkt...

[ Voor 15% gewijzigd door randommen op 07-07-2021 10:00 ]

[RL600]

@randommen ook dat is gecontroleerd

Daarnaast zou het dan gek zijn dat E1000 daar geen problemen mee heeft.

[ Voor 50% gewijzigd door RL600 op 07-07-2021 10:01 ]

[FireDrunk]

Dan zou switchen naar E1000 niet uit moeten maken. Klinkt alsof de VirtIO Drivers niet helemaal goed werken.
Zeggen de kernel logs van de host of de guests iets bij het inladen van de VirtIO driver(s)?

[joecks]

randommen schreef op woensdag 7 juli 2021 @ 09:34:
@joecks kijk eens naar je cgroups, lxc is een container en daar is iets in veranderd geloof ik.

Ik heb dat even bekeken Een mogelijkheid is het updaten van het host systeem of de systemd, deze zitten beide al op de laatste versie dus Ik ga maar proberen of ik de container kan migreren naar een VM ..

[randommen]

@joecks ik las ook ergens "Ik heb nu voor de gein een container van Buster naar Bullseye geupgrade, en dan is het geheugengebruik weer als voorheen..."

Volgens mij moet dat ook wel lukken in een lxc container als je de repos aanpast, de vraag is of je dat wilt.

[RL600]

@FireDrunk @randommen geen idee, maar het werkt weer. Tijdens debuggen gingen de pings ineens goed.

@FireDrunk Ik zie verder geen rare error (ook niet van voorheen)

Zal wel goed zijn nu. Yeah, proxmox!

Heb ook even gekeken naar de andere VM's. Het lijkt weer te werken als je een paar keer switched tussen E1000 en VirtIO. Een nieuwe VM pakt hem wel meteen netjes op.

[ Voor 27% gewijzigd door RL600 op 07-07-2021 10:20 ]

[zx9r_mario]

Ik ben wel benieuwd hoe btrfs werkt als raid oplossing ipv zfs in Proxmox 7.0. Zfs neemt redelijk veel werkgeheugen in beslag van de node. Zou dit ook met btrfs het geval zijn? En natuurlijk de performance.

Synology gebruikt btrfs voor raid (aangezien hun NAS systemen relatief weinig geheugen en cpu power hebben.)

[ Voor 21% gewijzigd door zx9r_mario op 07-07-2021 10:53 ]

[Keeper of the Keys]

Ik heb gisteren net voor het eerst een 6.4 test systeem geïnstalleerd (ben serieus aan het overwegen om VMware hiermee te vervangen), wat kan ik beter doen herinstallatie met 7.0 of upgrade proberen en zo leren over hun upgrade proces?

[raymonvdm]

Keeper of the Keys schreef op woensdag 7 juli 2021 @ 10:57:
Ik heb gisteren net voor het eerst een 6.4 test systeem geïnstalleerd (ben serieus aan het overwegen om VMware hiermee te vervangen), wat kan ik beter doen herinstallatie met 7.0 of upgrade proberen en zo leren over hun upgrade proces?

Upgrade proces en daarna de herinstallatie

[Keeper of the Keys]

Hehe, werkt het upgrade proces überhaupt als je (nog) geen betaald account hebt?

[Lightning7]

Bij mij lijkt de update van 6 naar 7 in een keer goed te zijn gegaan. Zorg wel ervoor dat je goed deze pagina naloopt: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0. Vooral die pve6to7 had nog een aantal waarschuwingen die ik even heb opgelost voordat ik de upgrade doorvoerde.

[ Voor 6% gewijzigd door Lightning7 op 07-07-2021 11:59 ]

[EverLast2002]

Keeper of the Keys schreef op woensdag 7 juli 2021 @ 11:58:
Hehe, werkt het upgrade proces überhaupt als je (nog) geen betaald account hebt?

Ja.
Subscription is om support te krijgen.
Proxmox zonder betaald account werkt helemaal hetzelfde als met betaald account.
(als ik LearnLinuxTV op YT goed begrepen heb).

[Keeper of the Keys]

Ik dacht dat er ook een verschil was tussen tot welke repositories je toegang hebt?

[EverLast2002]

Keeper of the Keys schreef op woensdag 7 juli 2021 @ 12:06:
Ik dacht dat er ook een verschil was tussen tot welke repositories je toegang hebt?

Ik heb deze checklijst bij de hand:
YouTube: Before I do anything on Proxmox, I do this first...

[Polyphemus]

Ik heb mijn host van 6.4 geüpgrade naar 7.0 zonder problemen, maar inderdaad gebruiken mijn Buster-containers nu meer geheugen.

Voor de gein heb ik er twee geüpgrade naar Bullseye en dan is het geheugengebruik weer als 'vanouds'. Het vreemde is, dat als ik de nesting-optie van de container op 0, default, laat staan, ik een vertraging na het invoeren van mijn password heb, voordat de prompt verschijnt. Zet ik nesting op 1, dan krijg ik meteen een prompt in de container...

[EverLast2002]

Polyphemus schreef op woensdag 7 juli 2021 @ 13:20:
Ik heb mijn host van 6.4 geüpgrade naar 7.0 zonder problemen, maar inderdaad gebruiken mijn Buster-containers nu meer geheugen.

Voor de gein heb ik er twee geüpgrade naar Bullseye en dan is het geheugengebruik weer als 'vanouds'. Het vreemde is, dat als ik de nesting-optie van de container op 0, default, laat staan, ik een vertraging na het invoeren van mijn password heb, voordat de prompt verschijnt. Zet ik nesting op 1, dan krijg ik meteen een prompt in de container...

Hier ook een Debian ct 10 naar 11 upgrade gedaan.
Geheugen geeft nog steeds verkeerde waarde aan in het dashboard (browser cache geleegd)
Dashboard 62MB, cli (free -h) 18MB

[A1AD]

joecks schreef op woensdag 7 juli 2021 @ 09:00:
Na de upgrade doet bij mij alles het weer alleen docker in LXC start niet meer op ...
Ik kom tot de volgende logging maar ik kom er niet verder mee , iemand die mij op weg kan helpen ?

service docker start

code:

Job for docker.service failed because the control process exited with error code.
See "systemctl status docker.service" and "journalctl -xe" for details.
root@NginxPM /#

systemctl status docker.service

code:

* docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2021-07-07 06:56:16 UTC; 43s ago
     Docs: https://docs.docker.com
  Process: 741 ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS (code=exited, status=1/FAILURE)
 Main PID: 741 (code=exited, status=1/FAILURE)
      CPU: 155ms

Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Consumed 155ms CPU time.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Service RestartSec=100ms expired, scheduling restart.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
Jul 07 06:56:16 NginxPM systemd[1]: Stopped Docker Application Container Engine.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Consumed 155ms CPU time.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.

journalctl -xe

code:

-- 
-- The job identifier is 764.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Start request repeated too quickly.
Jul 07 06:56:16 NginxPM systemd[1]: docker.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.service has entered the 'failed' state with result 'exit-code'.
Jul 07 06:56:16 NginxPM systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: A start job for unit docker.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit docker.service has finished with a failure.
-- 
-- The job identifier is 713 and the job result is failed.
Jul 07 06:56:16 NginxPM systemd[1]: docker.socket: Failed with result 'service-start-limit-hit'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.socket has entered the 'failed' state with result 'service-start-limit-hit'.
Jul 07 06:56:16 NginxPM systemd[1]: docker.socket: Consumed 1ms CPU time.
-- Subject: Resources consumed by unit runtime
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit docker.socket completed and consumed the indicated resources.
Jul 07 06:57:01 NginxPM CRON[765]: pam_unix(cron:session): session opened for user root by (uid=0)
Jul 07 06:57:01 NginxPM CRON[766]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Jul 07 06:57:01 NginxPM CRON[765]: pam_unix(cron:session): session closed for user root

Ik draai ook verschillende Docker instanties in LXC-containers. Maar even wachten met upgraden zeker...

[joecks]

@A1AD Dat lijk mij wel verstandig. ik heb zojuist even een nieuw container aangemaakt op basis van Debian turnkey core 16.1.1 en daarop Docker geïnstalleerd , gelijk al foutmelding dat deze niet gestart kon worden. Misschien dat het op een andere manier wel mogelijk is maar dat weet ik niet.

[krijn1985]

joecks schreef op woensdag 7 juli 2021 @ 15:42:
@A1AD Dat lijk mij wel verstandig. ik heb zojuist even een nieuw container aangemaakt op basis van Debian turnkey core 16.1.1 en daarop Docker geïnstalleerd , gelijk al foutmelding dat deze niet gestart kon worden. Misschien dat het op een andere manier wel mogelijk is maar dat weet ik niet.

Probeer eens een LXC container met debian bullseye (als die er nog niet is zul je een buster container moeten upgraden naar bullseye). Ik gok dat door veranderingen/toevoegingen van cgroups v2 een buster LXC er nu niet goed mee over weg kan. Ik heb namelijk een tijdje geleden ook problemen met bullseye LXC in proxmox 6.3 en daarin werkte met zelfde instelling etc docker ook niet. Het leek dat het probleem kwam door cgroups v2 dingen die de bullseye container verwachte. Ik heb dit toen niet kunnen oplossen en gokte dat het kwam door een verouderde kernel en/of oudere LXC.

Ik heb zelf nog geen tijd om over te gaan naar 7.0 om dit te testen.

[joecks]

krijn1985 schreef op woensdag 7 juli 2021 @ 16:10:
[...]


Probeer eens een LXC container met debian bullseye (als die er nog niet is zul je een buster container moeten upgraden naar bullseye). Ik gok dat door veranderingen/toevoegingen van cgroups v2 een buster LXC er nu niet goed mee over weg kan. Ik heb namelijk een tijdje geleden ook problemen met bullseye LXC in proxmox 6.3 en daarin werkte met zelfde instelling etc docker ook niet. Het leek dat het probleem kwam door cgroups v2 dingen die de bullseye container verwachte. Ik heb dit toen niet kunnen oplossen en gokte dat het kwam door een verouderde kernel en/of oudere LXC.

Ik heb zelf nog geen tijd om over te gaan naar 7.0 om dit te testen.

Wat vaag allemaal , ik heb dus handmatig een upgrade gedaan naar bullseye , daarna starte mijn docker wel zonder fouten alleen waren alleen al mijn docker containers verdwenen. Vervolgens opnieuw de docker containers aangemaakt en in portainer verschenen ze daarna ook weer met de originele aanmaakdatum en config.

Zal morgen even goed kijken of alles weer werkt zoals voorheen, bedankt voor het opweg helpen.

[RobertMe]

krijn1985 schreef op woensdag 7 juli 2021 @ 16:10:
[...]


Probeer eens een LXC container met debian bullseye (als die er nog niet is zul je een buster container moeten upgraden naar bullseye). Ik gok dat door veranderingen/toevoegingen van cgroups v2 een buster LXC er nu niet goed mee over weg kan. Ik heb namelijk een tijdje geleden ook problemen met bullseye LXC in proxmox 6.3 en daarin werkte met zelfde instelling etc docker ook niet. Het leek dat het probleem kwam door cgroups v2 dingen die de bullseye container verwachte. Ik heb dit toen niet kunnen oplossen en gokte dat het kwam door een verouderde kernel en/of oudere LXC.

Ik heb zelf nog geen tijd om over te gaan naar 7.0 om dit te testen.

Volgens mij moeten de cgroups echt identiek zijn. Ik heb toentertijd Alpine geprobeerd te draaien in LXC met dan Docker en die faalde ook op afwijkende / voor Alpine / Docker niet bestaande cgroups.

Edit:
Overigens sluit ook ik dan aan in het rijtje v.w.b. "ik wacht wel dat iemand weet hoe het werkende te krijgen / houden". Maar vermoed inderdaad ook dat Bulseye in LXC gewoon zal werken.

[ Voor 9% gewijzigd door RobertMe op 07-07-2021 16:51 ]

[Polyphemus]

EverLast2002 schreef op woensdag 7 juli 2021 @ 13:46:
[...]


Hier ook een Debian ct 10 naar 11 upgrade gedaan.
Geheugen geeft nog steeds verkeerde waarde aan in het dashboard (browser cache geleegd)
Dashboard 62MB, cli (free -h) 18MB

Heb deze info nog gevonden:
https://forum.proxmox.com...eleased.92007/post-401347

[krijn1985]

joecks schreef op woensdag 7 juli 2021 @ 16:48:
[...]


Wat vaag allemaal , ik heb dus handmatig een upgrade gedaan naar bullseye , daarna starte mijn docker wel zonder fouten alleen waren alleen al mijn docker containers verdwenen. Vervolgens opnieuw de docker containers aangemaakt en in portainer verschenen ze daarna ook weer met de originele aanmaakdatum en config.

Zal morgen even goed kijken of alles weer werkt zoals voorheen, bedankt voor het opweg helpen.

Mooi dat het weer lijkt te draaien in ieder geval (en dat ik nu waarschijnlijk ook weet waarom het bij mij niet werkte). Wel apart dat de containers waren verdwenen. Hoe start je normaal je containers? Met docker-compose?

[smesjz]

Gaat toch niet lekker na upgrade. USB devices worden niet meer goed herkend in LXC container.

Ze verschijnen gewoon met lsusb en ook /dev/ttyUSB0 bestaat.

Maar:
/usr/bus/usb/001/006 bestaat niet in LXC maar wel in host:

lxc-start 103 20210707212827.111 DEBUG conf - conf.c:mount_entry:2135 - Flags for "/dev/ttyUSB0" were 4098, required extra flags are 2
lxc-start 103 20210707212827.111 DEBUG conf - conf.c:mount_entry:2179 - Mounted "/dev/ttyUSB0" on "/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/ttyUSB0" with filesystem type "none"
lxc-start 103 20210707214840.570 DEBUG conf - conf.c:mount_entry:2116 - Remounting "/dev/ttyUSB0" on "/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/ttyUSB0" to respect bind or remount options

Debug laat geen errors zien maar het werkt niet beetje jammer dus morgen maar eens kijken naar downgrade.

[Zenix]

Meer mensen last met docker inderdaad https://forum.proxmox.com...de-from-6-4-to-7-0.92034/ het is dus combinatie van docker versie en OS.

[ Voor 15% gewijzigd door Zenix op 08-07-2021 01:24 ]

[smesjz]

Hier is uiteindelijk het probleem opgelost door lxc.cgroup2.devices.allow te gebruiken.
Dat hadden ze ook wel bij pve6to7 script mogen geven als warning want het sloopt uiteindelijk je containers.

pve6to7 --full klaagt ook dat je niet lxc.cgroup hebt ipv lxc.cgroup2..

[Zenix]

smesjz schreef op donderdag 8 juli 2021 @ 05:45:
Hier is uiteindelijk het probleem opgelost door lxc.cgroup2.devices.allow te gebruiken.
Dat hadden ze ook wel bij pve6to7 script mogen geven als warning want het sloopt uiteindelijk je containers.

pve6to7 --full klaagt ook dat je niet lxc.cgroup hebt ipv lxc.cgroup2..

Top. Hoe heb jij veder de USB passthrough gedaan?

[smesjz]

Zenix schreef op donderdag 8 juli 2021 @ 10:14:
[...]


Top. Hoe heb jij verder de USB passthrough gedaan?

code:

lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none,bind,optional,create=file

[EverLast2002]

Polyphemus schreef op woensdag 7 juli 2021 @ 21:54:
[...]

Heb deze info nog gevonden:
https://forum.proxmox.com...eleased.92007/post-401347

De Proxmox host zelf geeft wel de correcte geheugenwaarde in het Dashboard.

[nero355]

zx9r_mario schreef op woensdag 7 juli 2021 @ 10:50:
Ik ben wel benieuwd hoe btrfs werkt als raid oplossing ipv zfs in Proxmox 7.0.
ZFS neemt redelijk veel werkgeheugen in beslag van de node. Zou dit ook met btrfs het geval zijn? En natuurlijk de performance.

Synology gebruikt btrfs voor raid (aangezien hun NAS systemen relatief weinig geheugen en cpu power hebben.)

Synology gebruikt BTRFS alleen als FS laag en gebruikt niet de Software RAID functies ervan voor zover ik weet dus dat kan je niet echt met elkaar vergelijken...

[smesjz]

smesjz schreef op donderdag 8 juli 2021 @ 05:45:
Hier is uiteindelijk het probleem opgelost door lxc.cgroup2.devices.allow te gebruiken.
Dat hadden ze ook wel bij pve6to7 script mogen geven als warning want het sloopt uiteindelijk je containers.

pve6to7 --full klaagt ook dat je niet lxc.cgroup hebt ipv lxc.cgroup2..

Ik zag dit vandag bij de release notes van de updates van pve-manager:

code:

pve-manager (7.0-9) bullseye; urgency=medium

  * pve6to7: sync new checks and adaptions from stable-6 branch for consistency

En draaien van pve6to7 geeft nu wel een warning op lxc.cgroup

code:

INFO: Checking container configs for deprecated lxc.cgroup entries
WARN: The following CTs have 'lxc.cgroup' keys configured, which will be ignored in the new default unified cgroupv2:
    CT 107
    Often it can be enough to change to the new 'lxc.cgroup2' prefix after the upgrade to Proxmox VE 7.x

Als ik paar dagen had gewacht met upgraden had ik al die problemen dus niet gehad omdat het netjes wordt vermeld wat je moet doen. Jammer alleen dat het niet vanaf dag 1 er in zit.

[Zenix]

Ik wacht wel tot Debian 11.1 en Proxmox 7.1.

Vergeet niet dat Promox 6 nog gewoon twee jaar ondersteuning heeft

[orvintax]

smesjz schreef op vrijdag 9 juli 2021 @ 20:26:
[...]


Ik zag dit vandag bij de release notes van de updates van pve-manager:

code:

pve-manager (7.0-9) bullseye; urgency=medium

  * pve6to7: sync new checks and adaptions from stable-6 branch for consistency

En draaien van pve6to7 geeft nu wel een warning op lxc.cgroup

code:

INFO: Checking container configs for deprecated lxc.cgroup entries
WARN: The following CTs have 'lxc.cgroup' keys configured, which will be ignored in the new default unified cgroupv2:
    CT 107
    Often it can be enough to change to the new 'lxc.cgroup2' prefix after the upgrade to Proxmox VE 7.x

Als ik paar dagen had gewacht met upgraden had ik al die problemen dus niet gehad omdat het netjes wordt vermeld wat je moet doen. Jammer alleen dat het niet vanaf dag 1 er in zit.

Tja dat kun je verwachten als je meteen naar een nieuwe versie gaat updaten

[zeroday]

Zenix schreef op vrijdag 9 juli 2021 @ 20:51:
Ik wacht wel tot Debian 11.1 en Proxmox 7.1.

Vergeet niet dat Promox 6 nog gewoon twee jaar ondersteuning heeft

Ik wacht ook nog wel. Las dat PBS ook nog niet lekker werkt (en ik draai die onder Proxmox)
(correct me if Im wrong ..
even een weekendje weg geweest.

Voor mij valt het wel mee, het draait in een VM . .hoef me niet druk te maken ..

[ Voor 10% gewijzigd door zeroday op 12-07-2021 09:40 ]

[michielRB]

Ik sta op het punt om een thuislab op te zetten met proxmox: 3 compute nodes (i7, 16GB, 250GB SSD) en een HP microserver G8 met Truenas als target waar de VM's op komen. De 3 proxmox nodes zijn dus in feite puur compute nodes die live migratie mogelijk moeten maken.
Nu heb ik geen monitor en toetsenbord. Is er een optie om Proxmox VE headless te installeren? Ik heb op het PM forum gezocht en kwam daar niet echt verder, dus ik vrees dat het niet lukt, maar misschien is er hier iemand die me kan aangeven of dat kan en hoe?
Op zich mag het bleeding edge zijn (PM ve7) want het is meer m'n prive speeltuin dan dat er echt productie op gedraaid moet worden.
In het uiterste geval moet ik op zoek naar een monitor en een toetsenbord...

[GioStyle]

-

[ Voor 100% gewijzigd door GioStyle op 30-10-2022 07:14 ]

[Zenix]

@michielRB Heb je geen HPE iLo?

[ Voor 7% gewijzigd door Zenix op 12-07-2021 17:00 ]

[michielRB]

Niet op die computenodes. Dat zijn in feite sff pc's...

GioStyle schreef op maandag 12 juli 2021 @ 16:50:
Ik heb ook geen monitor meer in huis. Op het moment dat ik een monitor nodig heb plug ik hem in mijn tv.

Niet aan gedacht, dat zou nog een optie kunnen zijn. Dan heb ik alleen nog een el cheapo tobo nodig. Die zou ik voor 2 euro bij de kringloop vandaan kunnen halen...

[ Voor 77% gewijzigd door michielRB op 12-07-2021 17:07 ]

[dcm360]

Een andere wat avontuurlijke route kan ook nog via een VM. Installeer Proxmox in een VM, en kloon de virtuele schijf vervolgens naar de schijf die je in een echte machine gaat gebruiken (of misschien kan je de schijf ook wel direct aan de VM koppelen). Let er dan wel op dat je per node een installatie moet doen, anders ga je issues krijgen met ID's die uniek zouden moeten zijn en toch hetzelfde blijven.

[michielRB]

Al is het om te ontdekken of dat kan, ga ik proberen!....

[Verwijderd]

Proxmox Backup Server 2.0 is uit.

https://www.proxmox.com/en/news/press-releases/proxmox-backup-server-2-0-available

Directe ISO download link

Kunnen we weer fijn vanuit Proxmox VE 7.0 backuppen

[ Voor 18% gewijzigd door Verwijderd op 13-07-2021 14:49 ]

[michielRB]

Dat was ook nodig want ik las dat BS 1 niet samenging met (update naar) VE 7.

[Loekie]

Hier draaide de image backup prima verder anders?
Maar zal client backup vanuit vm zijn geweest?

[EverLast2002]

Kunnen we weer fijn vanuit Proxmox VE 7.0 backuppen

Dat kon al.
Heb je PBS 1.x (virtueel) draaien op dezelfde Proxmox 7 host > PBS werkt niet.
Heb je PBS 1.x draaien op een andere server of in een niet PVE 7 host > PBS werkt.

[Animal]

Ik krijg hier ook met geen mogelijkheid Turnkey met Docker aan de gang(proxmox 7).
Eerst geen overlay system(Ik heb de module handmatig aan moeten zetten)
en nu cgroup problemen (https://forum.proxmox.com...ing-pve-6-4-to-7-0.92459/)

Ook wil een template(container) met debian 10 niet eens opstarten.
Zijn dit allemaal proxmox 7 problemen?

Zoja; wil ik een fresh install doen met proxmox 6.4
Kan ik mijn bestaande Homeassistant os VM backuppen en later restoren in proxmox 6?

[ Voor 20% gewijzigd door Animal op 17-07-2021 22:02 ]

[smeerbartje]

Verwijderd schreef op dinsdag 13 juli 2021 @ 14:48:
Proxmox Backup Server 2.0 is uit.

https://www.proxmox.com/en/news/press-releases/proxmox-backup-server-2-0-available

Directe ISO download link

Kunnen we weer fijn vanuit Proxmox VE 7.0 backuppen

Ik backup nu gewoon naar een NFS mount (Synology) in Proxmox. Wat zijn de voordelen van een dedicated backup server eigenlijk?

[Zorian]

Ik heb dus een Proxmox bak draaien in een datacenter met een klein slootje WAN IP's. Echter is mijn "voorraadje" op maar wil ik nog meer VM's erop draaien. Kan ik zeg maar somehow instellen dat ik 1 WAN IP kan delen met meerdere VM's? Beetje alsof de server bij me thuis staat en de VM's daar ook internet krijgen via DHCP/NAT? Kan er weinig duidelijke info over vinden helaas.

[strandbal]

OPNsense vm inrichten en de rest van je vm's daar achter zetten?

[CurlyMo]

Zorian schreef op zaterdag 24 juli 2021 @ 14:53:
Ik heb dus een Proxmox bak draaien in een datacenter met een klein slootje WAN IP's. Echter is mijn "voorraadje" op maar wil ik nog meer VM's erop draaien. Kan ik zeg maar somehow instellen dat ik 1 WAN IP kan delen met meerdere VM's? Beetje alsof de server bij me thuis staat en de VM's daar ook internet krijgen via DHCP/NAT? Kan er weinig duidelijke info over vinden helaas.

Dat kan. Gewoon een router container installeren (zoals OpenWRT) die intern met DHCP adressen uitdeelt aan containers die dan eventueel via NAT naar buiten mogen.

Zo doet ik dat zelf ook met een VPS met één WAN ip. Daar draait een router en een reverse proxy op. Elke website draait in een eigen container die elk een uniek intern ip adres hebben.

[ Voor 12% gewijzigd door CurlyMo op 24-07-2021 14:56 ]

[Zorian]

strandbal schreef op zaterdag 24 juli 2021 @ 14:55:
OPNsense vm inrichten en de rest van je vm's daar achter zetten?

Maar hoe verbind ik die VM's aan de OPNsense VM dan? Moet ik dan nog een extra bridge maken op de host ofzo?

CurlyMo schreef op zaterdag 24 juli 2021 @ 14:55:
[...]

Dat kan. Gewoon een router container installeren (zoals OpenWRT) die intern met DHCP adressen uitdeelt aan containers die dan eventueel via NAT naar buiten mogen.

Zo doet ik dat zelf ook met een VPS met één WAN ip. Daar draait een router en een reverse proxy op. Elke website draait in een eigen container die elk een uniek intern ip adres hebben.

Het idee is dat ik diverse VM's heb die gescheiden van elkaar draaien maar wel allemaal internet nodig hebben.
Wat bedoel je met de containers? Ik draai geen docker in de VM namelijk bijvoorbeeld.

[ Voor 54% gewijzigd door Zorian op 24-07-2021 14:58 ]

[strandbal]

Ja, z'n "interne" nic hang je aan een extra bridge, waar je je vm's ook aan hangt. Je opnsense vm is dan de router en firewall.

[Zorian]

strandbal schreef op zaterdag 24 juli 2021 @ 14:58:
Ja, z'n "interne" nic hang je aan een extra bridge, waar je je vm's ook aan hangt. Je opnsense vm is dan de router en firewall.

En heb je daar dan een OVS bridge voor nodig op de host die je aan beide VM's koppelt?
Ben wat dat betreft een expert en tegelijk een noob

//Denk dat ik het geintje door heb, eens even proberen/spelen ermee.

[ Voor 8% gewijzigd door Zorian op 24-07-2021 15:13 ]

[nero355]

Zorian schreef op zaterdag 24 juli 2021 @ 14:57:
Maar hoe verbind ik die VM's aan de OPNsense VM dan? Moet ik dan nog een extra bridge maken op de host ofzo?

Inderdaad een Bridge opzetten, daarop de pfSense VM koppelen en gelijk ook ervoor zorgen dat je pfSense VM wat extra pootjes heeft in elke Bridge van de extra VM's

Het idee is dat ik diverse VM's heb die gescheiden van elkaar draaien maar wel allemaal internet nodig hebben.

Dat moet allemaal lukken!

[Zorian]

nero355 schreef op zaterdag 24 juli 2021 @ 15:40:
[...]

Inderdaad een Bridge opzetten, daarop de pfSense VM koppelen en gelijk ook ervoor zorgen dat je pfSense VM wat extra pootjes heeft in elke Bridge van de extra VM's


[...]

Dat moet allemaal lukken!

Hij werkt, was simpeler dan ik dacht! Bedankt allen.

//Nu alleen nog uitvogelen hoe ik van buitenaf een VM kan benaderen die achter OPNsense zit. Zal wel een firewall dingetje wezen vermoed ik.

[ Voor 15% gewijzigd door Zorian op 24-07-2021 16:33 ]

[powerboat]

Zorian schreef op zaterdag 24 juli 2021 @ 15:45:
[...]

Hij werkt, was simpeler dan ik dacht! Bedankt allen.

//Nu alleen nog uitvogelen hoe ik van buitenaf een VM kan benaderen die achter OPNsense zit. Zal wel een firewall dingetje wezen vermoed ik.

Vpn voor beheer en de diensten met haproxy afhandelen (is eventueel een plugin van opnsense)

[Sp33dFr34k]

Ik heb het probleem dat mijn Docker host VM draaiend op Ubuntu Server elke keer over de zeik is na een backup. Ik ben al geswitched van "stop" naar "snapshot", maar mag niet baten. Oplossing is de VM een keer rebooten, maar snap niet waarom dat nodig moet zijn. Ben ik de enige met dit probleem?

[A1AD]

Ter info: https://forum.proxmox.com...es-about-every-day.91803/

[powerboat]

A1AD schreef op donderdag 29 juli 2021 @ 08:03:
Ter info: https://forum.proxmox.com...es-about-every-day.91803/

Hmmm... Toch even wachten met upgraden van mijn epyc cluster.

Op mijn intel cluster merk ik dat sommige vm's uit staan terwijl ik zeker wist dat deze aanstonden.

Dacht dat ik spoken zag

[orvintax]

Er is al een temporary fix, zelfs in de non-subscription repos voor een aantal van die problemen. Maar zien jullie ook die kernel panick net zoals op de fora? @Sp33dFr34k @powerboat

[powerboat]

orvintax schreef op donderdag 29 juli 2021 @ 10:21:
Er is al een temporary fix, zelfs in de non-subscription repos voor een aantal van die problemen. Maar zien jullie ook die kernel panick net zoals op de fora? @Sp33dFr34k @powerboat

Heb de epyc cluster nog niet geupgrade, vanwege dit (heb ervaring).

Bij het intel cluster zie ik enkel dat een aantal vm's uitstaan. Ben nu aan het controleren waardoor het komt.

[dcm360]

orvintax schreef op donderdag 29 juli 2021 @ 10:21:
Er is al een temporary fix, zelfs in de non-subscription repos voor een aantal van die problemen. Maar zien jullie ook die kernel panick net zoals op de fora? @Sp33dFr34k @powerboat

De non-subscription-repo heeft normaalgesproken updates eerder dan de enterprise-repo. Pas als updates en wijzigingen grondiger getest en gevalideerd zijn, gaan ze door naar de enterprise-repo. Op die manier heb ik de 5.11-kernel ook al even geprobeerd op Proxmox 6.4, met maar matige resultaten (de netwerkinterfaces stopten iedere dag).

Op 1 server heb ik overigens wel al de stap naar Proxmox 7 gemaakt, en tot zover is het probleem daar vooral dat ik nog een container had met een te oude systemd. Aangezien de problemen gerelateerd lijken te zijn aan een hogere load, wacht ik eerst nog even af voordat ik andere machines ga upgraden, deze server doet niet zo veel.

[ Voor 20% gewijzigd door dcm360 op 29-07-2021 13:51 ]

[Koepert]

Vraagje.. ik heb een container aangemaakt waar AdGuard (script installer) op draait. AdGuard geraakt eens in de zoveel tijd (tussen 7 en 14 dagen ruwweg) unresponsive..

Is er in Proxmox een containersetting die een soort ' slaapstand' veroorzaakt?

Container is een kale Debian 10 template met een user, sudo en AdGuard en verder niets extra geinstalleerd.

Nesting & keyctl staan aan. Unpriviliged en Geen Protection.

DNS staat op "use host system" en daarbij vraag ik me af of dat goed gaat, hoewel de host mn fritzbox als DNS gebruikt.. die weer AdGuard als DNS heeft.. Ergens voelt dat niet ok. Maar K weet ook niet goed wat daar dan oorzaak is van deze failure.

Log toont niets ivm vastlopen. Er draait op deze container ook geen BU/Snapshot die het kan veroorzaken.

Iemand een suggestie?

[A1AD]

Koepert schreef op donderdag 29 juli 2021 @ 14:20:
Vraagje.. ik heb een container aangemaakt waar AdGuard (script installer) op draait. AdGuard geraakt eens in de zoveel tijd (tussen 7 en 14 dagen ruwweg) unresponsive..

Is er in Proxmox een containersetting die een soort ' slaapstand' veroorzaakt?

Container is een kale Debian 10 template met een user, sudo en AdGuard en verder niets extra geinstalleerd.

Nesting & keyctl staan aan. Unpriviliged en Geen Protection.

DNS staat op "use host system" en daarbij vraag ik me af of dat goed gaat, hoewel de host mn fritzbox als DNS gebruikt.. die weer AdGuard als DNS heeft.. Ergens voelt dat niet ok. Maar K weet ook niet goed wat daar dan oorzaak is van deze failure.

Log toont niets ivm vastlopen. Er draait op deze container ook geen BU/Snapshot die het kan veroorzaken.

Iemand een suggestie?

Er is momenteel een bug in Adguard als je DoH gebruikt (naar buiten toe). Wanneer er timeouts zijn op je netwerk stopt de DoH implementatie. Misschien heb je daar last van?