Description of problem: live-migration with --block-migrate results in a zero console log. Version-Release number of selected component (if applicable): libvirt version: 0.10.2, package: 18.el6 How reproducible: always Steps to Reproduce: 1. configure share ssh pubkey between the two hosts. 2. do block live mgiration by libvirt's CLI: virsh migrate --live --copy-storage-all --verbose <vm-name> qemu+ssh://<target-host>/system or by virt-manager refer in the link: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-Virtualization-KVM_live_migration-Migrating_with_virt_manager.html 3. results in a zero console log Actual results: can migrate successfully, but there is a zero console.log in target host. Expected results: hope the console.log in source host and target host are the same. Additional info: The console log is necessary to diagnose many kinds of problems, including errors reported by Anaconda, problems with the boot images, a misconfigured VM, failures in the harness, network problems communicating with Beaker...
Just trying to understand your question, why would you expect the console log (which is related to boot) be updated when live migration is performed?
Kashyap, not updated but moved to destination host along with the VM. Please consider situation when operator live migrates VM only for host maintenance. After host maintenance he will live migrate VM back to original host and I think that in such case console.log should still be there (e.g. transferred to destination host with VM and then back to original host).
(In reply to Pawel Koniszewski from comment #2) > Kashyap, not updated but moved to destination host along with the VM. > > Please consider situation when operator live migrates VM only for host > maintenance. After host maintenance he will live migrate VM back to original > host and I think that in such case console.log should still be there (e.g. > transferred to destination host with VM and then back to original host). Pawel, seems like there's general agreement from libvirt upstream that this needs to be handled at a higher-layer than libvirt. [Below is a comment from IRC, by Dan Berrangé, on this topic] "This bug is basically asking for the block migration functionality to extend to other qemu devices backed by files. This is pretty tricky in general, because with latest libvirt & qemu, qemu doesn't even get acess to the log files. It just gets given an anonymous pipe file descriptor, so it has no ability to migrate the log file even if it wanted to. libvirt tries to only concern itself with what happens on a single-node so moving stuff between nodes is left to the app using libvirt which knows better what to do".
Pawel agrees (on #openstack-nova on Freenode) that, it "sounds fair that higher-layer should handle this, yes" So, closing the bug with the rationale in comment#3