Search results

Translation: I read the instructions and the forum posts but I ignored them and the things happened as described but it is someone else's fault.

You are 100% sure that the samba share is working and correctly mounted? The most common reason for this problem is that the share has become not-mounted and backups are being written to the mount directory on the rootfs.

Did you try saying "yes" to the message?

DMA = Direct Memory Access. More or less all PCI devices support it. Direct transfers between devices or devices and memory without the CPU being involved. The whole point of the IOMMU is the protect against arbitrary transfers similar to what the MMU does for memory. The groups are configured...

It should be noted that this solution completely breaks security. Any VM can use DMA to access any other VM's devices.

192.168.0.0/16 is for private networks and because everyone uses them they aren't unique and therefore cannot be routed over the Internet. You also can't just set up a local DNS, nobody will know how to reach it. That is why you need to pay for resolveable names and have the DNS hosted somewhere...

Also, if you have any kind of PCI pass-through enabled on that VM all memory must be allocated on VM start. This is because DMA can access any part of the guest's memory at any time.

You would normally configure the VM's for the whole cluster to be on the same network.

IOW, it helps a lot to know how things work. That beats any "guide" every day of the week. It might take time but it is time well spent.

Somebody is stealing disks out of the data center? Or whole machines? Because once the server is up and running the disk is decrypted. FDE does not protect against inside jobs by data center employees who have access to the hypervisor. It does protect against your homelab machine being stolen...

Maybe the actually paying subscribers have other priorities?

Most of those would appear to just be warnings. Apparently you have ECC memory and some errors were corrected, which could be a problem down the road. There are some errors related to the video adapter, but PVE doesn't really use that. Do you have an actual problem?

One could try reading the manual: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_cluster_network_requirements 5.7.1. Network Requirements The Proxmox VE cluster stack requires a reliable network with latencies under 5milliseconds (LAN performance) between all nodes to operate stably.

They are copied to the initramfs when you update it.

It isn't a matter of software configuring. You need a crossover (sometimes called a "null modem") cable that swaps pins 2 and 3 of the serial connectors. You can buy such a thing on Amazon for $10 US.

The Windows time (in the taskbar) seems to be correct, or at least roughly matches the PVE time. The upload time in the Geekbench page could come from anywhere. Like maybe it comes from the server you upload to. ETA: Windows versions I have used all want the "RTC is local time" setting. There...

Firmware for your wifi/bluetooth card is what it is complaining about, not microcode which is for the CPU. You need to install pve-firmware and that will hopefully have the correct firmware for your card. I'm not sure why you care about wifi though since it does not work very well with PVE.

The same site also suggests the PC-Net NIC as the only one that is supported by both Qemu and OS/2.

This might be helpful. It is about using an out-of-the-box Qemu, but some of it will apply to a managed Qemu like PVE. https://www.os2world.com/wiki/index.php?title=OS/2_Warp_4_Install_under_QEMU_Notes

Yes, set the IDRAC time to UTC and it will be fine (after a reboot...the IDRAC/BIOS clock is only read on startup). Or you could let chrony step the clock to the correct time and then use "hwclock -w" to write the system time to the hardware clock. You don't need both. This assumes that you have...