Change Details

These 3 tickets represent an implementation for the live migration feature https://reviews.freebsd.org/D30954, as specified in the first ticket. This feature sends the guest's memory while it is still running. To do this, it uses migration rounds. In the first round, all the memory is sent over. In subsequent rounds, because the guest is still running and its memory can be modified anytime, only the modified pages since the last round are sent over in order to update the destination's memory. Currently, it uses a fixed number of rounds, 4 (this may be changed in the future). After these rounds finish, the source guest is stopped and the remaining modified memory pages are sent over, alongside the kernel structures' and emulated devices' states. Once this is completed, the guest can be resumed at the destination. For detecting the pages that were modified between rounds, we use a flag (VPO_VMM_DIRTY) for each vm_page. This flag is set each time vm_page->dirty field is updated but can only be reset when the page is migrated. The features works only for IPv4 guests that use wired memory (-S option for bhyve). Moreover, the migration procedure works only between identical workstations. More information regarding the implementation can be found here: - [[ https://www.bsdcan.org/2019/schedule/events/1079.en.html | Migrating a bhyve guest (BSDCan 2019) ]] - [[ https://www.bsdcan.org/events/bsdcan_2020/schedule/session/36-testing-and-profiling-warm-and-live-migration-in-bhyve/ | Testing and Profiling Warm And Live Migration In bhyve ]] The usage of the feature is detailed here: [[ https://github.com/FreeBSD-UPB/freebsd-src/wiki/Virtual-Machine-Migration-using-bhyve | Virtual Machine Migration using bhyve ]]. This first part adds command line parameters and parsing for live migration.

These 2 tickets represent an implementation for the live migration feature https://reviews.freebsd.org/D30954, as specified in the first ticket. This feature sends the guest's memory while it is still running. To do this, it uses migration rounds. In the first round, all the memory is sent over. In subsequent rounds, because the guest is still running and its memory can be modified anytime, only the modified pages since the last round are sent over in order to update the destination's memory. Currently, it uses a fixed number of rounds, 4 (this may be changed in the future). After these rounds finish, the source guest is stopped and the remaining modified memory pages are sent over, alongside the kernel structures' and emulated devices' states. Once this is completed, the guest can be resumed at the destination. For detecting the pages that were modified between rounds, we use a flag (VPO_VMM_DIRTY) for each vm_page. This flag is set each time vm_page->dirty field is updated but can only be reset when the page is migrated. The features transfers only through IPv4. The migration procedure works only between identical workstations. More information regarding the implementation can be found here: - [[ https://www.bsdcan.org/2019/schedule/events/1079.en.html | Migrating a bhyve guest (BSDCan 2019) ]] - [[ https://www.bsdcan.org/events/bsdcan_2020/schedule/session/36-testing-and-profiling-warm-and-live-migration-in-bhyve/ | Testing and Profiling Warm And Live Migration In bhyve ]] The usage of the feature is detailed here: [[ https://github.com/FreeBSD-UPB/freebsd-src/wiki/Virtual-Machine-Migration-using-bhyve | Virtual Machine Migration using bhyve ]]. This first part adds the VPO_VMM_DIRTY bit and related functions in the virtual memory system, as well as an ioctl to search for such dirty pages.

These 32 tickets represent an implementation for the live migration feature https://reviews.freebsd.org/D30954, as specified in the first ticket. This feature sends the guest's memory while it is still running. To do this, it uses migration rounds. In the first round, all the memory is sent over. In subsequent rounds, because the guest is still running and its memory can be modified anytime, only the modified pages since the last round are sent over in order to update the destination's memory. Currently, it uses a fixed number of rounds, 4 (this may be changed in the future). After these rounds finish, the source guest is stopped and the remaining modified memory pages are sent over, alongside the kernel structures' and emulated devices' states. Once this is completed, the guest can be resumed at the destination. For detecting the pages that were modified between rounds, we use a flag (VPO_VMM_DIRTY) for each vm_page. This flag is set each time vm_page->dirty field is updated but can only be reset when the page is migrated. The features works only for IPv4 guests that use wired memory (-S option for bhyve). Moreover,transfers only through IPv4. theThe migration procedure works only between identical workstations. More information regarding the implementation can be found here: - [[ https://www.bsdcan.org/2019/schedule/events/1079.en.html | Migrating a bhyve guest (BSDCan 2019) ]] - [[ https://www.bsdcan.org/events/bsdcan_2020/schedule/session/36-testing-and-profiling-warm-and-live-migration-in-bhyve/ | Testing and Profiling Warm And Live Migration In bhyve ]] The usage of the feature is detailed here: [[ https://github.com/FreeBSD-UPB/freebsd-src/wiki/Virtual-Machine-Migration-using-bhyve | Virtual Machine Migration using bhyve ]]. This first part adds commthe VPO_VMM_DIRTY bit and line parameterrelated functions in the virtual memory system, as well as and parsing ioctl to search for live migrationsuch dirty pages.