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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Dec 19, 2019 at 2:48 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>
> 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.

Keeping it as two commands allows you to start up the fork and let it
run immediately and only start up QEMU when you notice it is needed.
The idea being that you can monitor the kernel and see when it tries
to do some I/O that would require the QEMU backend. If you combine the
commands that option goes away. Also, QEMU itself isn't getting forked
right now, we just start a new QEMU process with the saved-state
getting loaded into it. I looked into implementing a QEMU fork command
but it turns out that for the vast majority of our use-cases QEMU
isn't needed at all, so developing that addition was tabled.

Tamas

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