February 22, 20188 yr Hi I tried to search if this bug was already reported, but I could not find it. I admit that i did not browse through the dozens of result pages so if this is duplicate, please feel free to remove my post. This looks like a small issue and with W/A... still, maybe it's worth sharing it. Description: Users will end up with orphaned VM vdisk file, if following a failed attempt to initially start the VM (enabled "Start VM after creation"), the user decides to cancel the VM definition. How to reproduce: 1) create VM with enabled checkbox "Start VM after creation" and allocate to VM more RAM than you have free in the system at that moment (this is easy to follow, so that VM will fail on first initialization, but for sure there are other ways to fail it) 2) Save 3) VM will fail to start due to not enough ram with an error like: VM creation error internal error: process exited while connecting to monitor: 2018-02-22T21:30:35.398973Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/2 (label charserial0) 2018-02-22T21:30:35.401988Z qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory 4) vdisk file is created 5) After dismissing the popup with the RAM allocation error, if user is pressing Cancel (instead of unchecking the "Start VM after creation" and pressing Done), then VM definition is lost, but vdisk is not deleted. Expected results: VM definition is saved, even if user is pressing Cancel after failure - since the user already pressed Create Actual results: VM definition is lost, VM does not appear in the list Other information: W/A - user needs to login to the terminal of the unraid (/mnt/user/domains/), identify the orphaned vdisk file and reclaim the space by manually removing it. I am not aware if other entities are left orphaned, besides the vdisk file. Edited February 22, 20188 yr by alexciurea
Archived
This topic is now archived and is closed to further replies.