Search results

No that won't work as debian tries to enable the ens18 interface before the cloud-init configuration. So even if you completely disable DHCP via Cloud-Init the VM still gets stuck during boot for 30-60s as it tries to obtain a IP via DHCP.

Hi, I eventually solved this issue by overwriting the included ens18 dhcp statement and setting the network config to manual. It took me countless hours to find the root cause for this issue as this isn't documented anywhere. The debian cloud team seems to assume there's always a DHCP server...

Any chance to set the port to anything else? I have a reverse proxy running on the Proxmox host which I cannot stop every time I have to renew the certificate

Yes das habe ich bereits alles durchgelesen. Hat jemand noch eine andere Idee?

The host crashed, or at least is unresponsive via UI/ SSH. Only a hard reset helps

Same issue here, can anyone report if the upgrade to 5.19 fixed the issue? I have a Ryzen system that randomly crashes every few days

Es werden die offiziellen Cloud Images genutzt. In dem Beispiel das aktuelle Debian 11 Cloud Image agent: 1 boot: c bootdisk: scsi0 cores: 1 cpu: host ide2: local-zfs:vm-9000-cloudinit,media=cdrom memory: 1024 meta: creation-qemu=6.2.0,ctime=1659619942 name: debian11 nameserver: 1.1.1.1 net0...

Of course does Proxmox work with IPv6, it’s basically a regular Debian based system

You have to use the No-Subscription repository if you dont have an active pve subscription https://pve.proxmox.com/wiki/Package_Repositories

Hi, Cloud-Init setzt bei jedem config change (hostname, SSH key etc.) einen neuen SSH hosts key, wodurch der SSH client dann per default eine Warnung wirft. Wenn ich das richtig verstanden habe, scheint cloud-init ohne metadata service davon auszugehen, dass es sich um eine neue Instanz...

Ich habe noch etwas weiter nachgeforscht aber konnte bisher leider immer noch keine Ursache finden. Die Konfiguration läuft exakt so auf einem weiteren Proxmox server problemlos. Wenn die Firewall für die VM deaktiviert und die VM rebooted wird, erreicht diese auch problemlos das Gateway...

Ich habe nun mittels tcpdump etwas näher nachgeforscht, auf dem Hostsystem kann ich allerdings keinerlei eingehende Pakete von der VM sehen. Auf der VM scheinen sie allerdings rauszugehen. Ich bin mittlerweile mit meinem Latein etwas am ende, hat jemand noch eine Idee? VM: 19:23:23.912481 IP...

Die IPs und MAC werden automatisch über die API zugewiesen, die sind unique. Ich habe die selbe Konfiguration auch auf einem zweiten System laufen, da gibt es keinerlei Probleme. Ich werde mal mittels tcpdump nachforschen

Hallo, Ich habe einen PVE Server mit NAT + Masquerading laufen. Der bridge vmbr0 habe ich das Netz 10.0.0.1/20 zugewiesen und den VMs IPs aus diesem Netz. Allerdings kann ich von keiner VM das Gateway oder andere Ziele erreichen. Vom Host aus erreiche ich die VM, allerdings erst nach einigen...

Hmm, irgendwie tauchen bei mir auch weiterhin eine zusätzliche Unused Disk 0 auf. Hier der API call 'scsi0' => "local-zfs:base-" . $templateid . "-disk-0,mbps_rd=" . $ioLimit . ",mbps_wr=" . $ioLimit, Resultat:

I did install qemu-guest-agent and resolvconf via virt-customize But the issue is the same on the vanilla image. Yes, but I guess the dhcp Definition itself is the problem, as there is no DHCP server running

https://askubuntu.com/a/1402305/1608729 Just found this by accident, this is exactly what I'm facing. To my surprise there actually exists a file called /run/network/interfaces.d/ens18 which configures the interface ens18 via dhcp auto ens18 allow-hotplug ens18 iface ens18 inet dhcp But...

The network itself seems to work, the VM get's a IPv6 IP, there's just a 1minute delay when booting. E1000 did not work in my testing, the VM was not able to get a IP. virtio also seems to also have better performance overall

I am using cloud-init. Edit: I mean my setup is quite similar to yours, the only thing I changed is using SLAAC for IPv6 and leaving IPv4 blank. So I'm not sure what is going on here

Very strange, but I suspect my issue is related to the interface renaming, but why is this even happening? Seems to work fine on other systems?