Search results

Hi, I take whatever hook we could get, I'd even take a start-stop-migration for KVM option in the HA management as with live we can not handle this issue in any way - and better to have a working networking-setup than a migrated KVM which is now offline for the world...

fyi - this should work on PMG: # proxmox repo "origin=Proxmox,codename=${distro_codename}";

We're currently relying on pre-start and post-stop hooks to basically configure the networking and routing for LXCs or KVMs. During PVE7.3 tests for HA and migration automation we experience the quite unexpected thing: The "loosing" PVE-node getting the LXC/KVM removed does execute the...

well, my point is merely the information is already provided via GUI - it would be nice to make it available within the PVE toolset.

Hi, is there a way to get automated warnings attached to the wearout-indication presented at the Host -> Disks view in PVE? (yes I know smartd, having this in the gui to notify admin-roles etc and specific wearout-levels for notifications would just be a plus) thx hk

Ein PVE6.4-15 wurde hart rebooted und nun häufen sich beim Start der Container diese Probleme. Versuche die VE Filesysteme zu checken enden hier: pct fsck 67107 fsck from util-linux 2.33.1 MMP interval is 300 seconds and total wait time is 1202 seconds. Please wait... und nach dem fsck der...

Hi, in order to be able to pin a TLS connection on the reciving end of PMG it would be great to be able to set the acme cert renewal to keep the privatekey during renewals. thank you in advance hk

the latest and greatest PVE 7.2 delivers frr-8.2.2 as a package. _but_ this release has a possible issue with ospf6d - for reference: https://github.com/FRRouting/frr/issues/10823 in order to fix this we installed frr-8.1 the following way: a) implement the apt-list config following the guide...

Hi, we do see this strange log also quite often and it _seems_ related to the lxc cpu-time issue, we get this _very_ often lxcfs[1161]: proc_fuse.c: 1018: proc_stat_read: cpu8 from /lxc/67106/ns has unexpected cpu time: 11596294 in /proc/stat, 13173683 in cpuacct.usage_all; unable to determine...

thx! the trick is to put _hostname_ in /etc/hosts, not the FQDN of the host, but the hostname part only - now spiceproxy is dual-stack reachable.

well, trying to get spice to work - and it always failed to connect to the server.... finally ending up tcpdumping on the host for port 3128... and there we got it: IPv6 calls are not answered, while after changing to IPv4 all is fine. probably because of this: tcp 0 0...

well, updating something that doesn't work is usually not our way of solving an issue :) so - in the end we found the culprit: "journalctl -b" is our friend. there we saw " networking[60]: ifup: pre-up script failed " the reason behind: we startup firewall-scripts before the interface goes up...

so basically lzo working was obviously an accident. the main issue here is the unprivileged users not being able to create a temp dir at the destination storage; in case of NFS the nfs-server should do a "root_squash" in its exports to work around this. (at least its a "works for us" solution)

well during tests we see the same on pve 6.2-4; backup seems to fail if the lxc is an unprivileged container; seems to work if the lxs is a privileged container; also this seems to happen only with zstd while lzo backups seem to work. and I'm pretty confused about this :)

well, eth0 is in fact within the container basically whatever name you'd like to name it. interfaces are adjusted correctly - otherwise a networking restart would not work either. after startup "ip a" only shows localhost, after networking restart all is well. I'm more looking for a way to...

Here is what we tried: moved an openvz container backup to a new proxmox, restores fine; networking also coming. updated debian v7 within the container to v8 now after every reboot of this container the "eth0" within the container is gone. after manually "/etc/init.d/networking restart" eth0...

well after updating today - tried this again. although the "pveversion -v" shows no difference to the releases above. now we get the controller loaded... currently not exactly trusting this.

sorry, but: journalctl -b -1 reports: Specifying boot ID or boot offset has no effect, no persistent journal was found.

well, after going back to the 5.3.18-3-pve we got our nvme back and lspci shows it again: Non-Volatile memory controller: Phison Electronics Corporation E12 NVMe Controller (rev 01) while on another box running 5.4.34-1-pve we got the samsung NVMe without problems: Non-Volatile memory...

well, just realised the NVMe storage associated with these VEs is gone in this box after the update... now this is really unexpected.