Bug 527188 - migrate --live deletes config file on poweroff
Summary: migrate --live deletes config file on poweroff
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-10-05 08:15 UTC by jbrackinshaw
Modified: 2010-03-16 17:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-12 08:40:57 UTC


Attachments (Terms of Use)

Description jbrackinshaw 2009-10-05 08:15:23 UTC
From bug 526919.

If I migrate a guest using migrate --live, and poweroff that guest, I have no config files left anywhere. I cannot power on the guest any more.

Comment 1 Daniel Veillard 2009-10-06 15:49:12 UTC
If the guest was not defined, i.e. no virsh define, just a create
then that's normal, the guest was transcient on the source and stay
transcient on the target. On the other hand if the guest was being defined
on the source, than IMHO it's a bug. What was you use case ?

Daniel

Comment 2 jbrackinshaw 2009-10-12 07:11:07 UTC
I can't see what the use for transient guests is (apart from to work around the weirdness of not deleting config files when a migrate is done).

Comment 3 Chris Lalancette 2009-10-12 08:40:57 UTC
(In reply to comment #2)
> I can't see what the use for transient guests is (apart from to work around the
> weirdness of not deleting config files when a migrate is done).  

It's mostly as a quick testing type environment, but it's also useful in this migration scenario.  That is, you can imagine:

1)  Migrate guest from A -> B
2)  Take down A for maintenance
3)  Bring A back up
4)  Migrate B -> A

In this case, maybe you never want to define the guest on B at all, since it's more or less just a container for it.

So there are scenarios you can construct for both defining and not defining the domain on the destination.  I'm going to post a patch that allows you to fine-tune this behavior in the API, in which case you'll get to choose.

I'm going to close this bug, though, since it's doing the intended thing at the moment (even if it doesn't quite fit your use case).  Feel free to re-open it if you disagree.

Chris Lalancette


Note You need to log in before you can comment on or make changes to this bug.