Juan Quintela wrote: > Luiz Capitulino <lcapitul...@redhat.com> wrote: > > On Wed, 21 Apr 2010 15:28:16 +0200 > > Kevin Wolf <kw...@redhat.com> wrote: > I tried a variation of this in the past, and was not a clear agreement. > > Basically, after a working migration to other host, you don't want to > allow "cont" on the source node (it target has ever changed anything, it > would give disk corruption).
This is not true if the target is using a copy of the disk. Making copies is cheap on some hosts (Linux btrfs with it's COW features). Forking a guest can be handy for testing things, starting from a known run state. The only thing to get confused is networking because of duplicate addresses, and there are host-side ways around that (Linux network namespaces). If I understand correctly, we can already do this by migrating to a file and copying the files. There's no reason to block the live equivalent, provided there is a way to copy the disk image when it's quiesced. So it's wrong to block "cont" on the source, but "cont --I_know_what_I_am_doing" might be good advice :-) > But my suggestion to disable "cont" after that got complains that people > wanted a "I_know_what_I_am_doing_cont". (not the real syntax). Perhaps > it is time to revise this issue? -- Jamie
