Hi Thomas,
We are still seeing this every once in a while. I can definitely tell
you that it is connected to older Linux Guest kernels and we have not
been able to identify a specific version which would make searching for
a fix commit a bit easier.
We are going to upgrade all our host kernels to
We have found a vm that recovered from a freeze and it seems like it has jumped
in time.
Below I have pasted a dump of tty1, it is ocr'd though so some characters could
have been misinterpreted.
hild
[13198552.767867] le-rss:010 Killed process 10374 (crop) total,r,4376400,
anon-rss,018, tl [13
Hi, this is an update after some extended tests and a fallback migration
to 4.14.
After doing another >10k migrations we are sure to say that we also encounter
this issue on kernel 4.14.
We migrate vpses from servers in serial (one after the other) mode. And we
notice that on some servers we enc
Hi David,
I have digged further into our issue and we have seen issues only when
migrating from servers that have a different tsc frequency.
Example:
Source (kernel 4.14.63)
[2.068227] tsc: Refined TSC clocksource calibration: 2593.906 MHz
[2.068373] clocksource: tsc: mask: 0x
Hi Jean,
Could you elaborate, is it the qemu patch that you applied and didn't
apply that to the current qem u version you are running?
Could you try to get a crash dump from a frozen vm working, see if you
get the same kind of backtrace in there.
Which specific qemu version are you running, whi
It seems like the patch is applied to the guests source kernel.
crash> clock_event_device
struct clock_event_device {
void (*event_handler)(struct clock_event_device *);
int (*set_next_event)(unsigned long, struct clock_event_device *);
int (*set_next_ktime)(ktime_t, struct clock_event
Is there a way that we can check that it indeed is the case that the clock
jumped a bit, we can try to read some kernel variables.
We just got another hung guest's crash dump working, this vm also shows a weird
uptime
DATE: Fri Dec 23 09:06:16 2603
UPTIME: 106752 days, 00:10:35
T
Hi Alan,
Dmesg shows nothing special:
[29891577.708544] IPv6 addrconf: prefix with wrong length 48
[29891580.650637] IPv6 addrconf: prefix with wrong length 48
[29891582.013656] IPv6 addrconf: prefix with wrong length 48
[29891583.753246] IPv6 addrconf: prefix with wrong length 48
[29891585.39794
A virsh dumpxml of one of the guests:
vps12
-953c-d629-1276-0616
4194304
4194304
2
/machine
hvm
Westmere
destroy
restart
restart
/usr/bin/kvm
https://bugs.launchpad.net/qemu/+bug/1831225
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/177
Title:
guest migration 100% cpu freeze bug
Status in QEMU:
Fix Released
Bug description:
# I
Public bug reported:
# Investigate migration cpu hog(100%) bug
I have some issues when migrating from kernel 4.14.63 running qemu 2.11.2 to
kernel 4.19.43 running qemu 2.11.2.
The hypervisors are running on debian jessie with libvirt v5.3.0.
Linux, libvirt and qemu are all custom compiled.
I mi
I do like to add that I only saw this when the source we migrate from is
running on a relatively new CPU: Intel(R) Xeon(R) Gold 6126 CPU @
2.60GHz.
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz
stepping: 4
guest xml definition:
vps25
0cf4666d-6855-b3a8-12da-2967563f
8388608
8388608
4
/machine
hvm
Westmere
destroy
restart
restart
/usr/bin/kvm
734003200
57
Public bug reported:
# Investigate migration cpu hog(100%) bug
I have some issues when migrating from qemu 2.6.2 to qemu 2.11.1.
The hypervisors are running kernel 4.9.92 on debian stretch with libvirt v4.0.0.
Linux, libvirt and qemu are all custom compiled.
I migrated around 21.000 vms from qem
om 18:39 heeft Kevin Wolf het volgende
> geschreven:
>
> [ Cc: qemu-block ]
>
> Am 22.03.2018 um 18:20 hat Dion Bosschieter geschrieben:
>> In commit 244a5668106297378391b768e7288eb157616f64 another
>> file descriptor to BDRVRawState is added. When we try to issue th
so it checks use_lock from BDRVRawState and
tries to reopen lock_fd accordingly
- change raw_reopen_commit so it closes the old lock_fd on use_lock
Signed-off-by: Dion Bosschieter
---
block/file-posix.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/block/file-posix.c
16 matches
Mail list logo