Bug 1425371
Summary: | Live migration fails | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | spamcop | ||||||||||||||||||||||
Component: | General | Assignee: | Dan Kenigsberg <danken> | ||||||||||||||||||||||
Status: | CLOSED DUPLICATE | QA Contact: | meital avital <mavital> | ||||||||||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||
Version: | 4.19.4 | CC: | bugs, michal.skrivanek, spamcop | ||||||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||
Last Closed: | 2017-02-28 10:48:25 UTC | Type: | Bug | ||||||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||||||
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||
Attachments: |
|
Description
spamcop
2017-02-21 09:47:30 UTC
Can you please attach complete VDSM logs of source and destination? You seem to shut down the guest in the middle of migration. Few warnings are expected in that case Created attachment 1256377 [details]
vdsm.log dest
Created attachment 1256379 [details]
vdsm.log source
(In reply to Michal Skrivanek from comment #2) > You seem to shut down the guest in the middle of migration. Few warnings are > expected in that case Any logs from guest then? It looks like a normal case of shutting down a guest (by you, or by the guest OS itself) Created attachment 1256387 [details]
engine.log
oVirt engine log is also attached.
Search for:
- ovirt-node-source.tld
- ovirt-node-dest.tld
- ovirt-engine.tld
- vm.tld
Created attachment 1256388 [details]
VM guest agent log
Guest agent log is attached.
Installed Packages
Name : ovirt-guest-agent-common
Arch : noarch
Version : 1.0.13
Release : 1.20161220085008.git165fff1.el7.centos
the guest agent log doesn't seem to be from the same time interval (problem happened at 10:05, the agent log starts at 10:26) What I meant was rather guest's system logs, like /var/log/messages or systemd journal as I suspect your guest simply decided to shut down normally, and it just so happens that it did that in the middle of migration, but it seems to be unrelated to that migration. Thanks! Created attachment 1256408 [details]
Migration 11:17 AM
Created attachment 1256409 [details]
Migration 11:17 AM
Created attachment 1256411 [details]
Migration 11:17 AM
Michal: unfortunately there are no other log entries in /var/log/messages, dmesg or journalctl but a new one in vdsm-source-20170222-1117.log. FYI: I just started another migration at 11:17 AM - the timestamp in every log file should be the same now. Sorry causing confusion. ok. thanks. in this case I can see that the VM doesn't run immediately after the migration is triggered. This is suspicious, it may be that the qemu process crashes immediately as a consequence of starting migration. Can you please dig out the corresponding systemd journal on host, and qemu.log in /var/log/libvirt/qemu/<vmname>.log? Created attachment 1256428 [details]
journal dest
Created attachment 1256429 [details]
journal source
Created attachment 1256430 [details]
qemu.log
Michal: are there any news concerning this issue? bug 1426727 is likely the same thing. Do you use QoS or any CPU profiles? When you see which PID is killing the VM, can you please get the process name? To see if it is libvirt or something else Yes, this is exactly the same issue (maybe anyone want to declare this ticket as duplicate). Migration is working again after renaming the clusters cpu profile to "Default" and set "QoS Name" to "[Unlimited]" thanks for confirmation, we now have a fix too. *** This bug has been marked as a duplicate of bug 1426727 *** |