Re: BHYVE_SNAPSHOT

Just add some plans for me:

 1. Describe snapshot file format: One file for snapshot.

 2. Implement snapshot/resume via nvlist.

   nvlist implementation brings:

Versioning
Easy debugging, getting saved values, etc.
Validate restored variables: types, sized, etc.
Add optional variables without breaking backward compatibility (resume can be performed with old snapshots)
Remove variables without breaking backward compatibility
Use one file for snapshot
Improve restore command line:  "bhyve -r $snapshot”, i.e. w/o additional arguments

——
Vitaliy Gusev

>>> 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