libvirt users - Jan 2014 - Re: Should domain be undefined after migration, or not?

I have been running a lab using libvirt under Debian Wheezy (libvirt 
0.9.12.3-1, qemu-kvm 1.1.2+dfsg-6, virt-manager 0.9.1-4). There are a 
number of machines as front-end servers and an nbd shared storage backend.

When I live-migrate a domain from one machine to another, normally I 
observe that afterwards the domain remains on the source host (but in 
"shutdown" state), as well as on the target host (in
"running" state).
But occasionally I have observed the domain being removed from the 
source host.

The trouble with the domain remaining on the source host is that it is 
all too easy to double-click on the shutdown domain in virt-manager and 
start it there accidentally, in addition to the copy on the target host 
- resulting in disaster. (I know this can be prevented using the sanlock 
plugin)

Furthermore, there could be stale copies of the XML lying around on some 
machines where the domain had been running at some point in the past.

My question is, what is the expected behaviour? Is not removing the 
domain definition from the source host a bug? Has this been changed in a 
newer version of libvirt?

Thanks,

Brian.

On 19/01/14 17:03, Brian Candler wrote:
> I have been running a lab using libvirt under Debian Wheezy (libvirt 
> 0.9.12.3-1, qemu-kvm 1.1.2+dfsg-6, virt-manager 0.9.1-4). There are a 
> number of machines as front-end servers and an nbd shared storage 
> backend.
>
> When I live-migrate a domain from one machine to another, normally I 
> observe that afterwards the domain remains on the source host (but in 
> "shutdown" state), as well as on the target host (in
"running" state).
> But occasionally I have observed the domain being removed from the 
> source host.
>
> The trouble with the domain remaining on the source host is that it is 
> all too easy to double-click on the shutdown domain in virt-manager 
> and start it there accidentally, in addition to the copy on the target 
> host - resulting in disaster. (I know this can be prevented using the 
> sanlock plugin)
>
> Furthermore, there could be stale copies of the XML lying around on 
> some machines where the domain had been running at some point in the 
> past.
>
> My question is, what is the expected behaviour? Is not removing the 
> domain definition from the source host a bug? Has this been changed in 
> a newer version of libvirt?
>
Brian, as far as I can tell, when you live migrate a domain you can use 
the flags --undefinesource and --persistent

The first one, as you can guess, will undefine the domain in the source 
host after migration succeeds. The second flag, combined with the first, 
may be the one troubling you. It is meant to leave the migrated domain 
transient in the destination host. That means once you shutdown the VM 
or migrate it, the domain will disappear from the domain list.

Hope this helps you.
> Thanks,
>
> Brian.
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>

On Sun, Jan 19, 2014 at 10:03:36PM +0600, Brian Candler
wrote:
> I have been running a lab using libvirt under Debian Wheezy (libvirt
> 0.9.12.3-1, qemu-kvm 1.1.2+dfsg-6, virt-manager 0.9.1-4). There are
> a number of machines as front-end servers and an nbd shared storage
> backend.
> 
> When I live-migrate a domain from one machine to another, normally I
> observe that afterwards the domain remains on the source host (but
> in "shutdown" state), as well as on the target host (in
"running"
> state). But occasionally I have observed the domain being removed
> from the source host.
> 
> The trouble with the domain remaining on the source host is that it
> is all too easy to double-click on the shutdown domain in
> virt-manager and start it there accidentally, in addition to the
> copy on the target host - resulting in disaster. (I know this can be
> prevented using the sanlock plugin)
> 
> Furthermore, there could be stale copies of the XML lying around on
> some machines where the domain had been running at some point in the
> past.
> 
> My question is, what is the expected behaviour? Is not removing the
> domain definition from the source host a bug? Has this been changed
> in a newer version of libvirt?
For historical reasons the default is to leave the config file
present on the source machine. You can control this behaviour
though when triggering migration. There are an insane number
of possible scenarios...

   http://libvirt.org/migration.html#config


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

On 20/01/2014 17:44, Daniel P. Berrange wrote:
> For historical reasons the default is to leave the config file
> present on the source machine. You can control this behaviour
> though when triggering migration. There are an insane number
> of possible scenarios...
>
>     http://libvirt.org/migration.html#config
Many thanks. It looks like --undefine-source --persist is what I was 
looking for. I'll need to dig a little deeper to see how virt-manager 
behaves.

I think the explanation for the behaviour I observed is when the VM was 
migrated from A -> B -> C, and I was watching the B -> C migration. It 
was persistent on A but transient on B.

Thanks again,

Brian.