On Fri, Oct 05, 2007 at 02:19:16PM +0900, Masaki Kanno wrote:
> Tue, 2 Oct 2007 15:47:12 +0100, "Daniel P. Berrange" wrote:
>
> >On Tue, Oct 02, 2007 at 10:11:01PM +0900, Masaki Kanno wrote:
> >> Hi Dan,
> >>
> >> Thanks for your effort and your patch.
> >> I think that the allow/reject rules are wonderful. But, I have a few
> >> comments.
> >>
> >>
> >> I agree the rule of the following case.
> >> But, the behavior is (redefine+rename+create), isn't it?
> >
> >Yes, that is actually what it ends up doing, replacing the config for the
> >matching UUID causes a rename.
> >
> >> When I tested the following case, the result was as follows.
> >> I think that we should reject xm new command if same UUID vm is active.
> >
> >I hadn't noticed that, but its easy to special case this particular
> >case / scenario to be rejected. Or we could fix it to correctly rename
> >the existing running VM which might be more user friendly.
> >
> >Either option is a small add-on patch to my previous submissions.
>
> Sorry for delay with replies to your message.
>
> I am worried about changing the configuration of existing running VM.
> But, my worry is vague, and does not have great grounds.
> If UUID is same, maybe we will become possible to change the name of
> the VM and all the configuration of the VM by xm new command, I guess.
>
> If only the config.sxp of the VM is changed by xm new command, and if
> the definition of the config.sxp is reflected after xm shutdown command,
> my worry will be resolved.
Kan, give this patch a try which simply updates the name_label field for
the exsting VM. With this minimal rename it avoids the risk of the same VM
being started twice as you demonstrated
Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
xen-active-rename.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|