JensU

Hi all. I recently upgraded unRaid from 6.9.2 to 6.11.5 ... all good, kind of. After the upgrade my Windows 10 VM would not start so I created a new VM with the new TPM 2.0 emulation and other features and pointed it to my original VM's disk ... The new VM started up but would not boot into Windows. I turns out I had installed Windows using MBR boot. I used MBR2GPT to do the conversion ... Windows now boots and I have my original VM working. For some of my Games I need to hide the VM from Windows so these games even load ... this was working like a charm before the upgrade, but the new VM was missing the required settings. After putting the same settings into the new VM to hide it from Windows ... it would keep freezing at the boot spinner of Windows. After much back and forth testing each setting, it turns out that the below setting is the culprit ... if its present Windows freezes at the spinner ... if I remove it everything is fine. I also believe this is one of the key settings to hiding the VM so I am a little stuck. <feature policy='disable' name='hypervisor'/> Here is my full VM XML ... without the above setting for now ... the VM works and I am using it to type this post ... as soon as I put it back Windows freezes at the spinner. <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>FATBOY</name> <uuid>28886274-c6f4-2bf1-d997-b0cc64e88b01</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>20971520</memory> <currentMemory unit='KiB'>20971520</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> </cputune> <resource> <partition>/machine</partition> </resource> <sysinfo type='smbios'> <bios> <entry name='vendor'>American Megatrends Inc.</entry> <entry name='version'>1505</entry> <entry name='date'>10/17/2014</entry> </bios> <system> <entry name='manufacturer'>ASUSTeK COMPUTER INC.</entry> <entry name='product'>P8H77-M PRO</entry> <entry name='version'>Rev X.0x</entry> <entry name='serial'>MT7025034403983</entry> <entry name='uuid'>28886274-c6f4-2bf1-d997-b0cc64e88b01</entry> <entry name='sku'>SKU</entry> <entry name='family'>H77</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-q35-5.1'>hvm</type> <smbios mode='host'/> </os> <features> <acpi/> <apic/> <hyperv mode='custom'> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='0123756792CD'/> </hyperv> <kvm> <hidden state='on'/> </kvm> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='4' threads='1'/> <cache mode='passthrough'/> <feature policy='disable' name='hypervisor'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <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='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/disks/sys/isos/Windows 10.iso'/> <backingStore/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/disks/sys/isos/virtio-win-0.1.190-1.iso'/> <backingStore/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/nvme0n1'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <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='pci' index='6' model='pcie-to-pci-bridge'> <model name='pcie-pci-bridge'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0xd'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/> </controller> <controller type='virtio-serial' index='0'> <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='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:2b:7f:d7'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x03' 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> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <audio id='1' type='none'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x1a' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x06' slot='0x01' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x1d' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x06' slot='0x02' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> <seclabel type='dynamic' model='dac' relabel='yes'/> </domain>

Its not a NUT "problem" nor a UPS problem it is simply a disconnect between the two ... We cannot change how the UPSs work and the connect/disconnect behaviour seems to be a very common one. If NUT simply keeps trying rather than giving up after the first attempt then this will be resolved, maybe allow for config on how often/long NUT should keep trying before sending an alert that the UPS has failed to connect. Right now the server boots and no one is informed that the UPS is not connected.

Hi there NUT not always starting on reboot. I have a common USB/Serial UPS connected via USB to my unRaid. Everything works just fine when NUT is running. However, I have now finally learned that most UPS's seem to disconnect from USB if they do not get a connection within 20s or so, then they reconnect. This is why when testing in windows you hear the connect/disconnect sounds over and over. Once the UPS gets a connection from the software/service it stays connected. My problem is that after a power failure or deliberate reboot, NUT is not guaranteed to be running because it tries once and if the UPS's 20s cyce is not in sync then NUT can't connect and does not start, but the UPS will connect again seconds later, but NUT does not try again. Is there a way to force NUT to keep trying to start until it succeeds, or to try longer. My logs are filled with the UPS connecting/disconnecting, once NUT starts the logging stops. Its just a timing thing between NUT and the UPS so if NUT just keeps trying it will connect. Right now my server restarts after a power failure but is often then not protected cos NUT is stopped and the next power failure there is not graceful shutdown. Grateful for any suggestions to get NUT to just try more than once to connect and start. Regards Jens

I will play with the VM Memory allocation and see what will/will not start. Interestingly though is that when the VM fails to start there is no indication of cached memory being released and the usage is the same before and after the failed start. If cached memory was released on demand I would expect this to happen and then be at a minimum after the vm failes to start.

When I look at the stats when my VM won't start I can see that the system is only using about 2gb Ram, Cached Ram sits at about 4-5Gb and it takes a day or two to get to this point.

Hi There I have an unRaid box with 8Gb Ram. I have several dockers running and some VM's I occasionally need to start up. After a fresh boot all is well. all dockers are running and I can start and stop VM's as I need to. However after some time the Cached Ram seems to grow and consume about 50% of my memory which is fine. I believe this is some drive directory cache etc which makes sens as I have about 20tb with plenty of files. The problem is that once this cache ram has grown enough I can no longer start my VM's and the only way I know how to clear the cached memory is a reboot. I don't really want to have to reboot my system just to fire up a VM. The VM is allocated 4Gm of the 8Gm of ram. Any ideas, suggestons. I do plan to add more ram but fear this will just allow the cached memory to grow even more. Thanks.