Bug 527188

Summary: migrate --live deletes config file on poweroff
Product: [Community] Virtualization Tools Reporter: jbrackinshaw
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: clalance, crobinso, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-12 08:40:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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