Date: Mon, 28 Feb 2022 18:12:00 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 262113] bhyveclt: Every second attempt to destroy->run fails with: invalid argument error Message-ID: <bug-262113-27103-Arw9zo7hfY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262113-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-262113-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262113 --- Comment #4 from risner <risner@stdio.com> --- As advised, I found it worked if I give it several second between the destr= oy and the creation of a new session. The destroy_dev_sched_cb() call is the scheduled task in the kernel. It appears to remove the /dev/vmm entry, but = not yet all the kernel entries are removed by the time the create call tries to= add them back. While looking at the code it felt to me this line: https://github.com/freebsd/freebsd-src/blob/22054f88914b51113f77f6eccc11353= a891f9f3e/usr.sbin/bhyve/bhyverun.c#L1081 Only covered the situation of "the VM still exists" and doesn't cover "the = VM is being destroy but not yet completely destroyed." In the case of it being destroyed, the code falls through to: https://github.com/freebsd/freebsd-src/blob/22054f88914b51113f77f6eccc11353= a891f9f3e/usr.sbin/bhyve/bhyverun.c#L1105 with an invalid argument return value vm_open() as it's been destroy by the time this happens. Is there no way to catch the scheduled destroy and return something other t= han EEXIST in the create to catch this state? Addressing the points brought up (lines beginning with >> are my responses): - the docs issue that would seem to imply destroy is necessary in certain cases. >> My confusion would have been alleviated by adding a note that destroy is= only needed if you have no plans to resume the vm and wish to free the wir= ed memory. - presumably we'd like a destroy/run cycle/procedure to either a) work, or,= at least b) have an improved user experience that an error every second attemp= t. >> Adding another state response distinct from EEXIST say perhaps ESHUTDOWN= if there is scheduled destroy, the error could be less confusing by respon= ding with "destroy in progress" or similar. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262113-27103-Arw9zo7hfY>