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

From: Tamas K Lengyel <tamas@tklengyel.com>
To: Julien Grall <julien.grall@gmail.com>
Cc: "Petre Pircalabu" <ppircalabu@bitdefender.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Tamas K Lengyel" <tamas.lengyel@intel.com>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <george.dunlap@eu.citrix.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Alexandru Isaila" <aisaila@bitdefender.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Anthony PERARD" <anthony.perard@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 00/20] VM forking
Date: Mon, 30 Dec 2019 17:37:38 -0700	[thread overview]
Message-ID: <CABfawh=F8dsn4LLtdfYR4nb0djaswofEioDtqi2TKVJ0zCBK0Q@mail.gmail.com> (raw)
In-Reply-To: <CAF3u54B2+3q90jFftH+ZcuhdH6i8cOEpjiOjrVdNJCiBSzBtng@mail.gmail.com>

On Mon, Dec 30, 2019 at 5:20 PM Julien Grall <julien.grall@gmail.com> wrote:
>
> Hi,
>
> On Mon, 30 Dec 2019, 20:49 Tamas K Lengyel, <tamas@tklengyel.com> wrote:
>>
>> On Mon, Dec 30, 2019 at 11:43 AM Julien Grall <julien@xen.org> wrote:
>> But keep in mind that the "fork-vm" command even with this update
>> would still not produce for you a "fully functional" VM on its own.
>> The user still has to produce a new VM config file, create the new
>> disk, save the QEMU state, etc.
>
>
>  If you fork then the configuration should be very similar. Right?
>
> So why does the user requires to provide a new config rather than the command to update the existing one? To me, it feels this is a call to make mistake when forking.
>
> How is the new config different from the original VM?

The config must be different at least by giving the fork a different
name. That's the minimum and it's enough only if the VM you are
forking has no disk at all. If it has a disk, you also have to update
the config to point to where the new disk is. I'm using LVM snapshots
but you could also use qcow2, or whatever else there is for disk-CoW.
The fork can also have different options enabled than it's parent. For
example in our test-case, the forks have altp2m enabled while the
parent VM doesn't. There could be other options like that someone
might want to enable for the fork(s). If there is networking involved
you likely also have to attach the fork to a new VLAN as to avoid
MAC-address collision on the bridge. So there are quite a lot of
variation possible, hence its better to have the user generate the new
config they want instead of xl coming up with something on its own.

>
> As a side note, I can't see any patch adding documentation.

It's only an experimental feature so adding documentation was not a
priority. The documentation is pretty much in the cover letter. I'm
happy to add its content as a file under docs in a patch (with the
above extra information).

Tamas

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