@marked23 : In my humble opinion the "issue" starts at a different place.
The "one-vm-on-the-hypvervisor" setup you describe is an edge-case. Hypervisors were built to have massive-parallel work to do, because all the time some of the VMs is doing a little. But not all VMs need everything the...
There might be even another option. It just popped into my mind.
Swap does not necessarily needs to be a partition. You could also use a file as swap-device.
Maybe this is something easier to accomplish?
Agree. There is no other answer than "it depends".
Pretty much the whole IO-profile plays a significant role.
Including the dependency of your hardware-setup (DMA-Access, Interrupts, etc.).
In my opinion you should primarily have a look on the CPU Oversubscription and memory assignment. I´d...
I have checked on my end and I can´t repro.
I am on 6.8.8-3 though.
What do your other machines run?
I have noticed that at some point the script took some time (likely because of slow storage answer times) but it then ran without any further issues.
Have you been patient enough?
@yamzvinz: As already stated you need to have sudo installed. Aside that if you don´t use the "-e" parameter the script will only work in "dry-mode", so it does not execute any action.
I'd try to use a different PCIe-Slot.
Also try to disable VT-d or similar virtualization technologies and all unneccessary IO-ports (e.g. serial connectors).
What exactly is slow and how much time does each individual step take?
To boot the vm? I think this is absolutely reasonable.
I do boot my VMs partially sequential, partiall parallel. In the end it takes some time to get them all up. I have never tried to do everything in parallel. it also...
I'd refer to my post here. Maybe the discussion in the thread is helpful as well:
https://forum.proxmox.com/threads/migrate-vms-from-proxmox-hyper-v.48682/#post-228123
IMHO forget timing and clockspeeds. This is old gear but I am taking almost any bet you won't notice the difference.
8GB more memory will boost your system more than faster memory.
I switched from PC3-10666 to PC3-8500 on my opteron - never felt a difference.
According to this post a BIOS update might be helpful. Disabling offloading does not seem to help.
https://forum.netgate.com/topic/175592/can-not-get-dhcp-leases-on-new-intel-i225-lm-based-machine/13
What BIOS version are you running? Is there a newer available?
This seems to be a Problem related to the chipset i225lm. You are not alone.
Check this:
https://www.reddit.com/r/Proxmox/comments/o2l7h0/i225lm_nic_dhcp_server_in_vm_not_working_it_does/
Sorry for the late reply. I hope you have already solved your issue.
Sometimes a NIC somewhat cripples UDP packets. I have seen this in the past on other Hypervisors.
What exact hardware are you using?
What directly do you mean by "directly connected"?
Are you using a switch? If not - maybe the interfaces are not early enough in "link up" state - that also means no dhcp request is received...
*eek* - no no no. Don't forget the hypervisor host.
At least spare 4 GB for PVE itself and you shouldn't assign 100% anyways.
This is not how virtualization works. This whole thread discusses the mechanisms of it.
But with the numbers mentionend you should be fine.
I'd take another approach...
It depends on your USB connection...
Attaching the USB to the VM works different to than on the host.
Imho. You should ignore the raw file and pass the disk through as described in the article.
You need to find were these 32 GB live.
This can be done via
du -h --max-depth=1
In the root folder. This will spit out the usage of each folder. CD into the folder and repeat the process.
You also can try using the cleanup script I have created. You can find it here...
Did you use zpool in sync io?
Guess not if arc fills up...
Give it a try:
https://dannyda.com/2020/08/23/how-to-check-change-modify-zfs-syncstandard-disabled-always/
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.