Re: [Xen-devel] [PATCH v2 00/20] VM forking

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Dec 18, 2019 at 11:40:37AM -0800, Tamas K Lengyel wrote:
> The following series implements VM forking for Intel HVM guests to allow for
> the fast creation of identical VMs without the assosciated high startup costs
> of booting or restoring the VM from a savefile.
> 
> JIRA issue: https://xenproject.atlassian.net/browse/XEN-89
> 
> The main design goal with this series has been to reduce the time of creating
> the VM fork as much as possible. To achieve this the VM forking process is
> split into two steps:
>     1) forking the VM on the hypervisor side;
>     2) starting QEMU to handle the backed for emulated devices.
> 
> Step 1) involves creating a VM using the new "xl fork-vm" command. The
> parent VM is expected to remain paused after forks are created from it (which
> is different then what process forking normally entails). During this forking
               ^ than
> operation the HVM context and VM settings are copied over to the new forked 
> VM.
> This operation is fast and it allows the forked VM to be unpaused and to be
> monitored and accessed via VMI. Note however that without its device model
> running (depending on what is executing in the VM) it is bound to
> misbehave/crash when its trying to access devices that would be emulated by
> QEMU. We anticipate that for certain use-cases this would be an acceptable
> situation, in case for example when fuzzing is performed of code segments that
> don't access such devices.
> 
> Step 2) involves launching QEMU to support the forked VM, which requires the
> QEMU Xen savefile to be generated manually from the parent VM. This can be
> accomplished simply by connecting to its QMP socket and issuing the
> "xen-save-devices-state" command as documented by QEMU:
> https://github.com/qemu/qemu/blob/master/docs/xen-save-devices-state.txt
> Once the QEMU Xen savefile is generated the new "xl fork-launch-dm" command is
> used to launch QEMU and load the specified savefile for it.

IMO having two different commands is confusing for the end user, I
would rather have something like:

xl fork-vm [-d] ...

Where '-d' would prevent forking any user-space emulators. I don't
thinks there's a need for a separate command to fork the underlying
user-space emulators.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel