Everything posted by Xyler94
-
Unable to modify VMs after creation, getting odd error
Hello, I'm currently using Version 7.0.0 of Unraid, but this issue started well before I upgraded to 7.0.0, I was hoping that this version resolved this issue. Started back in version 6.10.14. Whenever I go to change a value in a VM, be it adding more RAM, or changing the Virtual Graphics Driver, I get this error message pop up: However, I'm not passing through any PCIe devices to my VMs, and VM creation doesn't get this error. Here's the XML of this VM: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>Floof Gateway V2</name> <uuid>0d5b8a86-f87f-aca2-2ec3-7964c99bbeac</uuid> <metadata> <vmtemplate xmlns="unraid" name="Arch" icon="arch.png" os="arch"/> </metadata> <memory unit='KiB'>2621440</memory> <currentMemory unit='KiB'>2621440</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='20'/> <vcpupin vcpu='1' cpuset='21'/> <vcpupin vcpu='2' cpuset='22'/> <vcpupin vcpu='3' cpuset='23'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-7.2'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/0d5b8a86-f87f-aca2-2ec3-7964c99bbeac_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' clusters='1' cores='2' threads='2'/> <cache mode='passthrough'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/CacheDomain/FloofGatewayV2/vdisk1.img'/> <target dev='hdc' bus='scsi'/> <serial>vdisk1</serial> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/archlinux-2024.12.01-x86_64.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='scsi' index='0' model='virtio-scsi'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x8'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x9'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0xa'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0xb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0xc'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:45:ca:0e'/> <source bridge='br1'/> <model type='virtio-net'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <channel type='qemu-vdagent'> <source> <clipboard copypaste='yes'/> <mouse mode='client'/> </source> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <audio id='1' type='none'/> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </video> <watchdog model='itco' action='reset'/> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </memballoon> </devices> </domain> I'm unsure what is happening. I don't want to keep re-creating VMs every time I want to change a small aspect of a VM. It's getting rather frustrating to deal with...
-
[PLUGIN] GPU Statistics
I just want to say thank you to the forums here. I had an issue, but it was resolved with the suggestions of other people here. Keep up the great work developer(s), and hopefully everyone else has a good day!
-
Trying to Understand Cache Usage
Thank you very much for your help Jorge, With all your advice, the drive is now almost 200GB lighter. All VMs working just fine.
-
Trying to Understand Cache Usage
I followed the link, and did the steps for my Windows Server VM. It worked, Windows Server sees the drive as "Thin Provisioned" now I did not notice any mention of Linux. Is SCSI controller baked into Linux? and I just need to add the " discard='unmap' " code for my Linux VMs?
-
Trying to Understand Cache Usage
This did the trick. Dropped the usage down to 334GB. Gonna do more checks to make sure all the VMs come online properly, but wow... I wonder why the files balloon like that, it's weird.
-
Trying to Understand Cache Usage
It's the file size that Windows File Explorer shows when I look for the vdisk from the share itself.
-
Trying to Understand Cache Usage
Just a quick question while I'm trying things, By default, are the disks Thick or Thin provisioned? I check my Windows Server VM, and the vdisk size is 200GB, which is exactly what I set the limit as. This would indicate a thick provision from my understanding, no?
-
Trying to Understand Cache Usage
Okay, sounds good. I'll give it a shot. It may be my VMs causing this then, I'll have to shut down the VMs using the Cache pool, try a move and move back, and see if that helps. Thank you for your time!
-
Trying to Understand Cache Usage
Here is the diagnostics file. xylerserver-diagnostics-20240820-1025.zip
-
Trying to Understand Cache Usage
Hello, I've got an odd thing happening. I'm completely unsure what's been using up all my data in my cache pools. I look at my shares, and calculating all my shares that use my cache pools comes up to around 348GB of usage, but unraid is reporting the cache pools are at 450GB roughly of usage. I don't know where the extra almost 100GB is coming from, and it's been filling my cache drives (500GB SSDs) full. I was planning on buying more storage, but I'm not sure what's even causing my cache drives to fill up, and if will just be the same with more storage. What's the best way to check up on what's going on here? I'm baffled at this particular oddity.
-
Odd behaviours with Unraid CPU Usage
Never mind, I just redid the base VM and it came up no problem.
-
Odd behaviours with Unraid CPU Usage
Hi there, After moving the VMs I could to the cache, and doing other things like you suggested, it seems to have gone okay, but now one of my VMs aren't booting up properly. It simply boots to this, and now I'm worried I lost the data after moving it. I cut and paste instead of copy paste the files. While it's not technically a huge loss if I lost this VM, it was my Home Assistant VM, and setting that back up would be a nightmare... Thanks for your help so far though, I do really appreciate it!
-
Odd behaviours with Unraid CPU Usage
Like a Cache Pool? I did notice my Windows Server VM being odd when it was on the array. However, some stuff doesn't need the pure speed of the SSDs, and needs big storage. NextCloud for instance needs big storage, not necessarily big performance. I should move some things over to the SSD Cache Pool though. I should try that. There are a few VMs I could put on the Cache instead. Question though, should it be Cache only or should I do a Cache to Array with mover? I had mover enabled on my Cache domain once, and it caused oddities with Windows Server service game services, kept crashing the game server (minecraft especially).
-
Odd behaviours with Unraid CPU Usage
Okay, as long as it's normal, I'm not worried then. Disk 2 seems to contain my Home Assistant VM. Disk 3 contains my NextCloud VM (Although I would have liked that on Disk 1, I'm slowly upgrading my disks to Seagate Ironwolf drives) Disk 2 would make sense, Home Assistant logs many things, and there's a power monitoring device in the Zwave network I got going, and it constantly reports power usage. Disk 3, NextCloud would be reading and writing to synchronize with my desktop and phone for cloud storage. I'm now curious if it's NextCloud then. Or if someone's trying to bruteforce onto NextCloud. Other than that, I'm not writing anything to my array at the moment.
-
Odd behaviours with Unraid CPU Usage
I downloaded the logs (I attached it here if you're curious). What's odd to me that stuck out was in the "SMART" logs. That top "NVMe" doesn't look right, I only have 1 NVMe drive right now in my system For some reason, it shows the Sabrent Rocket NVMe drive twice in this folder, with different names. I checked both, and they're the same serial number. If this is simply my PC slowing down, I'm gonna be upgrading my server in the coming weeks, but I am curious what's causing this. xylerserver-diagnostics-20231115-1055.zip
-
Odd behaviours with Unraid CPU Usage
That would tell me the differences between the two, but that doesn't tell me why unraid seems less responsive than usual. I've been trying to figure why my unraid is spiking often. If you're saying the difference between these two may be iowait, then do I have an IO issue somewhere?
-
Odd behaviours with Unraid CPU Usage
Hi There, After upgrading to version 6.12.4, I've noticed my unraid's WebUI being slower than usual, and the CPU Spikes to 100% more often than usual. However, when looking at the HTOP output in the CLI, it doesn't match the CPU usage of the WebUI, so I'm sort of confused as to the issue. I know the WebUI and HTOP outputs don't refresh together, but the attached screenshot, the WebUI was like this for a few seconds, and the HTOP output refreshed several times before I took the screenshot. None of my Dockers or VMs are being sluggish, and none of them are showing signs that they're taking up system resources like this. I've attached a screenshot of the WebUI and HTOP views together. Was curious if this is normal behaviour. If it isn't, what are steps I can take to troubleshoot this, because I'm running low on options on things I've tried. Even rebooting doesn't seem to fully help. It isn't always at high utilization, but it does so often enough, and the WebUI is sluggish due to it.