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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

> >> I actually disagree that we want a single command to do all of these.
> >> If we did want `exec xl` to be one of the supported interfaces, I think
> >> it would break down something like this:
> >>
> >> `xl fork-domain`: Only forks the domain.
> >> `xl fork-launch-dm`: (or attach-dm?): Start up and attach the
> >> devicemodel to the domain
> >>
> >> Then `xl fork` (or maybe `xl fork-vm`) would be something implemented in
> >> the future that would fork the entire domain.
> >
> > I really don't have a strong opinion about this either way. I can see
> > it working either way. Having them all bundled under a single
> > top-level comment doesn't pollute the help text when someone is just
> > looking at what xl can do in general. Makes that command a lot more
> > complex for sure but I don't think it's too bad.
>
> One thing I don't like about having a single command is that since
> you're not planning on implementing the end-to-end "vm fork" command,
> then when running the base "fork-vm" command, you'll have to print an
> error message that says "This command is not available in its
> completeness; you'll have to implement your own via fork-vm --domain,
> fork-vm --save-dm, and fork-vm --launch-dm."
>
> Which we could do, but seem a bit strange. :-)

Yea, it's not a single step to get to a fully functional fork but its close:
1. pause parent vm
2. generate qemu_save_file
3. xl fork-vm -C config -Q qemu_save_file <parent_domid>

For the second fork - provided it has its own config file ready to go
- it is enough to just run the 3. step. Technically we could integrate
all these three steps into one and then the user would only have to
generate the new config file. But I found this setup to be "good
enough" already.

Tamas

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