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

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

On Thu, Dec 19, 2019 at 08:58:01AM -0700, Tamas K Lengyel wrote:
> 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.

I'm not sure I see why, you could still provide a `xl fork-vm [-c]
...` that would just lunch a QEMU instance. End users using xl have
AFAICT no way to tell whether or when a QEMU is needed or not, and
hence the default behavior should be a fully functional one.

IMO I think fork-vm without any options should do a complete fork of a
VM, rather than a partial one without a device model clone.

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

Starting a new process with the saved-state looks fine to me, it can
always be improved afterwards if there's a need for it.

Thanks, Roger.

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