<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'><div>Hi Roman,<br></div><div>Sorry for the delay (I didn't setup a correct filter for the mailing list and  missed your follow-up mail)<br></div><div><br></div><div>Updated patch looks awesome. thank you for your effort!<br></div><div><br></div><div class="zmail_extra"><blockquote style="border-left: 1px solid #cccccc; padding-left: 6px; margin:0 0 0 5px"><div><div>> Note 1: while adding tests I noticed that port allocator will actually <br></div><div>> skip already bound ports, so I'm wondering if it makes any sense to use <br></div><div>> virPortAllocatorSetUsed(.., true)? Right now I cannot come up with any <br></div><div>> case to trigger this except probably some races when spawning guests <br></div><div>> simultaneously, but that's hard to reproduce. <br></div></div></blockquote></div><div><br></div><div>Need to look at other drivers but I think it makes sense to use virPortAllocatorSetUsed (it's also thread-safe and has a lock)<br></div><div><br></div><div class="zmail_extra"><blockquote style="border-left: 1px solid #cccccc; padding-left: 6px; margin:0 0 0 5px"><div><div>> Note 2: there are still some cases where resources allocated during <br></div><div>> command preparation are not properly cleaned up; that's not only VNC <br></div><div>> ports, but also TAP devices. I plan to add proper cleanup routines <br></div><div>> separately. <br></div></div></blockquote></div><div><br></div><div>thanks.</div><div><br></div><div>--<br></div><div>alex<br></div><div><br></div><div><br></div><div><br></div><div class="zmail_extra"><div id="Zm-_Id_-Sgn1"><div><br></div><div>---- On Tue, 18 Jul 2017 14:03:23 +0300 <b>Roman Bogorodskiy <bogorodskiy@gmail.com></b> wrote ----<br></div></div><div><br></div><blockquote style="border-left: 1px solid #cccccc; padding-left: 6px; margin:0 0 0 5px"><div><div>Roman Bogorodskiy wrote: <br></div><div><br></div><div>> From: Alexander Nusov <<a href="mailto:alexander.nusov@nfvexpress.com">alexander.nusov@nfvexpress.com</a>> <br></div><div>> <br></div><div>> This patch adds support for automatic VNC port assignment for bhyve guests. <br></div><div>> --- <br></div><div>> Changes from v1: <br></div><div>> <br></div><div>>  * Call virPortAllocatorRelease() in virBhyveProcessStop() to release <br></div><div>>    VNC port; that's done unconditionally of using autoport <br></div><div>>  * Call virPortAllocatorSetUsed(.., true) in virBhyveProcessReconnect() <br></div><div>>    to reserve already used VNC ports after daemon restart <br></div><div>>  * Call virPortAllocatorSetUsed(.., true) in bhyveBuildGraphicsArgStr() <br></div><div>>    for domains that don't use autoport so allocator didn't try to use <br></div><div>>    ports allocated by these domains <br></div><div>>  * In dryRun mode (i.e. for domxml-to-native) don't allocate any ports <br></div><div>>  * Add a couple of unit tests <br></div><div>> <br></div><div>> Note 1: while adding tests I noticed that port allocator will actually <br></div><div>> skip already bound ports, so I'm wondering if it makes any sense to use <br></div><div>> virPortAllocatorSetUsed(.., true)? Right now I cannot come up with any <br></div><div>> case to trigger this except probably some races when spawning guests <br></div><div>> simultaneously, but that's hard to reproduce. <br></div><div>> Note 2: there are still some cases where resources allocated during <br></div><div>> command preparation are not properly cleaned up; that's not only VNC <br></div><div>> ports, but also TAP devices. I plan to add proper cleanup routines <br></div><div>> separately. <br></div><div>> <br></div><div>> <br></div><div>>  src/bhyve/bhyve_command.c                          | 25 +++++++++++-- <br></div><div>>  src/bhyve/bhyve_driver.c                           |  5 +++ <br></div><div>>  src/bhyve/bhyve_process.c                          | 20 +++++++++++ <br></div><div>>  src/bhyve/bhyve_utils.h                            |  3 ++ <br></div><div>>  .../bhyvexml2argv-vnc-autoport.args                | 12 +++++++ <br></div><div>>  .../bhyvexml2argv-vnc-autoport.ldargs              |  1 + <br></div><div>>  .../bhyvexml2argv-vnc-autoport.xml                 | 26 ++++++++++++++ <br></div><div>>  tests/bhyvexml2argvtest.c                          |  7 ++++ <br></div><div>>  .../bhyvexml2xmlout-vnc-autoport.xml               | 41 ++++++++++++++++++++++ <br></div><div>>  tests/bhyvexml2xmltest.c                           |  1 + <br></div><div>>  10 files changed, 138 insertions(+), 3 deletions(-) <br></div><div>>  create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.args <br></div><div>>  create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.ldargs <br></div><div>>  create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-vnc-autoport.xml <br></div><div>>  create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-vnc-autoport.xml <br></div><div><br></div><div>ping? <br></div><div><br></div><div>Roman Bogorodskiy <br></div><div>-- <br></div><div>libvir-list mailing list <br></div><div><a href="mailto:libvir-list@redhat.com">libvir-list@redhat.com</a> <br></div><div><a href="https://www.redhat.com/mailman/listinfo/libvir-list">https://www.redhat.com/mailman/listinfo/libvir-list</a><br></div></div></blockquote></div><div><br></div></div></body></html>