PeteAsking

No, I do not know how to do this.

Can I check how to edit the schedule? i added via the gui variables and guessed how to do it. In the xml it appears as such: <Variable> <Value>12</Value> <Name>CREATE_BACKUP_HOURS</Name> <Mode/> </Variable> <Variable> <Value>7</Value> <Name>PURGE_BACKUP_DAYS</Name> <Mode/> </Variable> Th GUI I set key as the description and value as the integer. Is that right?

Post your xml. Most likely you haven’t assigned the VM the windows installation media to boot up from.

I am surprised nobody else seems to have had this vnc duplicated/garbled display problem I am experiencing. Am I really the only one with this issue? I didnt do anything strange like pass graphics cards or anything. Its basically an unmodified xml other than changing ram size and processors dedicated to it etc.

Ok then try the above after you find out.

To further assist in reducing the memory footprint I have been working on the following: Assumptions for proposed changes: 1) You have less than 50 unifi devices being controlled by the controller. (Do not make these changes if your installation manages over 50 devices.) 2) Docker is limited to 2GB as per previous discussion. 3) The controller should sit around 1GB but may during busy periods use more. proposed edits: nano nano /mnt/disk1/appdata/unifi-controller/data/system.properties Interesting values: db.mongo.connections_per_host=64 db.mongo.threads_multiplier=3 Max number of threads allowed to write to the DB can be 64*3=192. (Default vaulue for controller is 100 and 5 = 500 threads). inform.max_keep_alive_requests=32 inform.num_thread=64 This sets the largest number of devices the controller can respond to to be 64, and that missed heartbeats from devices can be up to 32. (Default values are are 200 normally.) unifi.xms=256 unifi.xmx=768 Sets initial DB heap size to 256MB and Maximum heap size to 768MB (Default unifi expects is 2GB). Expected outcome: unifi controller will reduce memory usage, and compensate by increasing CPU usage on the docker controller as more time will be spent clearing out and writing to the database more often. Example system.properties file (bottom section shown): #Sat Jul 04 21:07:44 UTC 2020 db.mongo.connections_per_host=64 db.mongo.threads_multiplier=3 debug.device=warn debug.mgmt=warn debug.sdn=warn debug.system=warn inform.max_keep_alive_requests=32 inform.num_thread=64 is_configured_and_restarted=true is_default=false reporter-uuid=fb1782e2-e754-4e7b-a8c6-2015572f423c unifi.xms=256 unifi.xmx=768 uuid=088aa964-4245-4d3d-8a70-3f519c3e45b6 Please let me know how this goes for you with these changes. To revert, remove the 6 lines added into the settings file as above. Obviously once changes are made, the docker must be stopped and started again. Pete

You dont provide much info but did you do the basics like set the controller IP and the setting underneath it that says override inform host with controller ip?

Most likely spinners are really bad for VM's because you are most likly using a journalised filesystem on top on another journalised filesystem. Its also so coincidental that you mention the WDC_WD30EFRX drive because that was one of the model numbers in the recent smr/cmr debacle. I did double check and that is a cmr so you are safe there at least.

Thanks I will think further on it.

Fair enough. Was it still working when it was at 1.8GB?

So what happened?

Did you try just making a windows 10 vm from the gui and then overwriting the disk image unraid made with the one you have (ie rename it and copy it over) like I suggested yet?

Thank you to everyone who helped me increase the size of my disk. In the end only 1 method worked for me. I added a second disk then booted up of the installer disk in the VM (by choosing startup disk in system preferences) and once I created a partition on the new disk with disk utility I clicked the restore option in disk utility and restored from the smaller disk which seemed to clone the original disk to the destination disk. I could then boot from the new disk and remove the old one and delete the image. I also have another issue that is not a major problem but just annoying. Every time I shut down the VM and turn it back on the VNC graphics become garbled, like it is trying to display the screen many times in VNC. The way I have to fix it every time I ever turn off the VM, is to boot VM, go into the bios, choose OVMF settings and change resolution to 1920x1080 then save this and reboot. Graphics still garbled at this point. Shut down a second time and repeat the above changing the resolution to 800x600. This time when you boot the VNC graphics are normal and it is 1080p despite being set to 800x600 and I can use VNC as normal. If I ever turn off OSX I must repeat this 2 reboot process to restore the graphics. Its not a major issue as I dont reboot often and of course I avoid doing so unless I have to since its a headache to get the screen working again via vnc. I just wondered if anyone else had this issue and knew why it did it or how to fix it. Kind regards P

Do you have the original xml file at least from proxmox?

It is quite complicated. You would need to create a double nat setup where PFSense/OpnSense has the WAN as an ip on your existing LAN and the LAN is a new subnet not used on your network. A connecting client via openvpn etc would be placed into the lan on the pfsense box and be provided internet via NAT and be unable to communicate with anything other than the PFSense box. I feel this solution will not be suitable long term, as it only resolves 1 issue and anytime you need to extend the functionality of it you would run into issues. If you are not able to run your own equipment you may be at the mercy of what functionality is provided by your provider unless you are willing to change.