Date: Tue, 2 May 2023 01:16:15 -0500 From: Matthew Grooms <mgrooms@shrew.net> To: Rob Wing <rob.fx907@gmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-virtualization@freebsd.org, elenamihailescu22@gmail.com, Mihai Carabas <mihai.carabas@gmail.com>, gusev.vitaliy@gmail.com Subject: Re: BHYVE_SNAPSHOT Message-ID: <89c84bd7-a925-02f4-acbe-12c3000e7007@shrew.net> In-Reply-To: <CAF3%2Bn_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com> References: <ZEz8tU_83QfqbbMu@int21h> <fe221c6a-acb7-ddbd-413d-7039de33e872@shrew.net> <CAF3%2Bn_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------PosPzAVxthavBLdS0gbQcyBE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/30/23 21:31, Rob Wing wrote: > Hey Matthew, > > On Sun, Apr 30, 2023 at 1:41 PM Matthew Grooms <mgrooms@shrew.net> wrote: > > > Would you like to see support for VM snapshots in the generic kernel? > > > Is there a review open that addresses the limitations described in the > commit message that brought the snapshot feature in? > https://github.com/freebsd/freebsd-src/commit/483d953a86a2507355f8287c5107dc827a0ff516 Yes. The next set of project goals where not pulled out of thin air. They were selected specifically to address the limitations that prevented snapshots from being in the mainline kernel after the initial commit. That's why patches for AMD CPU, Multiple Devices ( >1 of the same type ), Capsicum and JSON file format for snapshots were developed. They were identified as the major per-requisite for lifting conditional compilation. > How about support for warm or live migration? > > > This builds off the snapshot work, right? Seems like it'd make more > sense to address the current limitations of the snapshot code before > extending the functionality off the top of it. > Yup. See above. I appreciate your input, but the goal of live migration was set in 2016 with a prototype first demonstrated in 2018. How long do you suggest a developer wait without review feedback before moving forward out of tree? > There are experimental patches for all these features that were > developed by students at UPB. In a lot of cases, there are open > reviews that have been waiting on feedback for ages. > > > In general, most people don't want to review large experimental patches. Yup. That approach was attempted with the Warm Migration patches. From slide 17 in Elena's presentation: First review opened in 2021: https://reviews.freebsd.org/D28270 5 reviews from 2022 starting with https://reviews.freebsd.org/D34717 (same feature split in multiple parts) A similar request was made recently to Gusev Vitaliy WRT the multiple device support patch which he took ownership of. Thanks for adding feedback to that review BTW. We'll see how that pans out ... https://reviews.freebsd.org/D35590 > > The case is quite plain. I'm not sure what the solution is to this > problem. I'd love to hear feedback from the community about how > I've got > this completely wrong and how the course could be corrected. That > would > be something. > > > My perspective is that it would have been better to focus student > efforts on completing the snapshot feature. By completing the snapshot > feature, I mean getting the code into a state where it's compiled in > by default and no longer considered an experimental feature. > I'm not sure what more to say hear regarding the snapshot feature or what might have been done in the past. We need a solution for the present. If you have any comments related to the follow up reviews submitted by UPB, I'm sure they'd love to hear them. And lastly: I get that FreeBSD is a non paid volunteer project for most. Without the efforts of folks like Peter, Neel, John and others, there would be no bhyve. I'm not saying that they, as project maintainers, should somehow be doing more. We all have limited time to invest, paid work to do and families to feed. I'm asking if there are other developers that might be willing and able to help with reviews? Is there something the FreeBSD foundation can do help out in situations like these? Thanks, -Matthew --------------PosPzAVxthavBLdS0gbQcyBE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 4/30/23 21:31, Rob Wing wrote:<br> </div> <blockquote type="cite" cite="mid:CAF3+n_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div>Hey Matthew,<br> </div> <br> <div class="gmail_quote"> <div dir="ltr" class="gmail_attr">On Sun, Apr 30, 2023 at 1:41 PM Matthew Grooms <<a href="mailto:mgrooms@shrew.net" moz-do-not-send="true" class="moz-txt-link-freetext">mgrooms@shrew.net</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Would you like to see support for VM snapshots in the generic kernel?<br> </blockquote> <div><br> </div> <div>Is there a review open that addresses the limitations described in the commit message that brought the snapshot feature in? <a href="https://github.com/freebsd/freebsd-src/commit/483d953a86a2507355f8287c5107dc827a0ff516" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/freebsd/freebsd-src/commit/483d953a86a2507355f8287c5107dc827a0ff516</a></div>; </div> </div> </blockquote> <p>Yes. The next set of project goals where not pulled out of thin air. They were selected specifically to address the limitations that prevented snapshots from being in the mainline kernel after the initial commit. That's why patches for AMD CPU, Multiple Devices ( >1 of the same type ), Capsicum and JSON file format for snapshots were developed. They were identified as the major per-requisite for lifting conditional compilation.<br> </p> <blockquote type="cite" cite="mid:CAF3+n_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> How about support for warm or live migration?</blockquote> <div><br> </div> <div>This builds off the snapshot work, right? Seems like it'd make more sense to address the current limitations of the snapshot code before extending the functionality off the top of it.<br> <br> </div> </div> </div> </blockquote> <p>Yup. See above. I appreciate your input, but the goal of live migration was set in 2016 with a prototype first demonstrated in 2018. How long do you suggest a developer wait without review feedback before moving forward out of tree?<br> </p> <blockquote type="cite" cite="mid:CAF3+n_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_quote"> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There are experimental patches for all these features that were developed by students at UPB. In a lot of cases, there are open reviews that have been waiting on feedback for ages.<br> </blockquote> <div><br> </div> <div>In general, most people don't want to review large experimental patches.<br> </div> </div> </div> </blockquote> <p>Yup. That approach was attempted with the Warm Migration patches. From slide 17 in Elena's presentation:<br> <br> First review opened in 2021: <a class="moz-txt-link-freetext" href="https://reviews.freebsd.org/D28270">https://reviews.freebsd.org/D28270</a><br>; 5 reviews from 2022 starting with <a class="moz-txt-link-freetext" href="https://reviews.freebsd.org/D34717">https://reviews.freebsd.org/D34717</a>; (same feature split in multiple parts)<br> <br> A similar request was made recently to Gusev Vitaliy WRT the multiple device support patch which he took ownership of. Thanks for adding feedback to that review BTW. We'll see how that pans out ...<br> <br> <a class="moz-txt-link-freetext" href="https://reviews.freebsd.org/D35590">https://reviews.freebsd.org/D35590</a><br>; </p> <blockquote type="cite" cite="mid:CAF3+n_fN4J4jXH89t8gMOD8QpqAike0Uzrb9wUfKoYv56zQt_w@mail.gmail.com"> <div dir="ltr"> <div class="gmail_quote"> <div> <br> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The case is quite plain. I'm not sure what the solution is to this <br> problem. I'd love to hear feedback from the community about how I've got <br> this completely wrong and how the course could be corrected. That would <br> be something.<br> </blockquote> <div><br> </div> <div>My perspective is that it would have been better to focus student efforts on completing the snapshot feature. By completing the snapshot feature, I mean getting the code into a state where it's compiled in by default and no longer considered an experimental feature.<br> <br> </div> </div> </div> </blockquote> <p>I'm not sure what more to say hear regarding the snapshot feature or what might have been done in the past. We need a solution for the present. If you have any comments related to the follow up reviews submitted by UPB, I'm sure they'd love to hear them.<br> </p> <p>And lastly: I get that FreeBSD is a non paid volunteer project for most. Without the efforts of folks like Peter, Neel, John and others, there would be no bhyve. I'm not saying that they, as project maintainers, should somehow be doing more. We all have limited time to invest, paid work to do and families to feed. I'm asking if there are other developers that might be willing and able to help with reviews? Is there something the FreeBSD foundation can do help out in situations like these?<br> </p> <p>Thanks,<br> </p> <p>-Matthew<br> </p> </body> </html> --------------PosPzAVxthavBLdS0gbQcyBE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89c84bd7-a925-02f4-acbe-12c3000e7007>