Re: BHYVE_SNAPSHOT

On Tue, 2023-05-02 at 01:16 -0500, Matthew Grooms wrote:
> 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?

The snapshot feature isn't compiled in by default. So, it's likely that
changes break it and only a few people are testing it.

We have to focus on getting this into the 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
> 

I've already reviewed Vitaliy's multi device support patch and people
had more than enough time to complain about it. I'm going to commit it
as soon as he splits his commit.
  
> > >  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
>  

UPB has developed some interesting features and I'd like to see those
in tree. I can take some time to review the patches. Nevertheless, we
really need the snapshot feature compiled in by default. Otherwise,
it's wasted time for all of us.


-- 
Kind regards,
Corvin