| Summary: | Migration during system_reset failed to bootup file system | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | xiywang |
| Component: | kernel-rt | Assignee: | Peter Xu <peterx> |
| kernel-rt sub component: | KVM | QA Contact: | Virtualization Bugs <virt-bugs> |
| Status: | CLOSED NOTABUG | Docs Contact: | |
| Severity: | high | ||
| Priority: | unspecified | CC: | bhu, juzhang, knoel, lcapitulino, peterx, riel, virt-maint, xiywang |
| Version: | 7.3 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-22 10:13:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
xiywang
2016-03-11 10:52:33 UTC
I have tested this case based on the newest rt kernel 3.10.0-364.rt56.241.el7 and 7.2 release version 3.10.0-327.rt56.204.el7. All the three versions (327, 355 and 364) share the same issue. I have a question about this test. One of the steps is this: "3. boot guest in dst host" At that point, is the guest running simultaneously on the src and dst hosts, simultaneously accessing the same filesystem from both instances? If so, that is expected to cause filesystem corruption (like you observed). (In reply to Rik van Riel from comment #4) > I have a question about this test. One of the steps is this: > > "3. boot guest in dst host" > > At that point, is the guest running simultaneously on the src and dst hosts, > simultaneously accessing the same filesystem from both instances? > > If so, that is expected to cause filesystem corruption (like you observed). No. The two guests are not running simultaneously. When the guest running in src host, the command for dst host to boot guest was added "-incoming tcp:0:4444", which means the guest in dst host was before migration and the result of "info status" was "paused". And the two guests were using different filesystem on each host, which I copied from src host to dst host before testing. (In reply to xiywang from comment #5) [...] > And the two guests were using different filesystem on each host, which I > copied from src host to dst host before testing. Could you explain what does "using different filesystem on each host" mean? AFAIK, we should make sure that both src and dst QEMU are using the same block device backend for migration (e.g., using NFS share folders to store the qcow2 file, and mount them on both sides). Am I correct? Peter (In reply to Peter Xu from comment #6) > (In reply to xiywang from comment #5) > > [...] > > > And the two guests were using different filesystem on each host, which I > > copied from src host to dst host before testing. > > Could you explain what does "using different filesystem on each host" mean? > AFAIK, we should make sure that both src and dst QEMU are using the same > block device backend for migration (e.g., using NFS share folders to store > the qcow2 file, and mount them on both sides). Am I correct? > > Peter I forgot to mount nfs the last time I tested this case. And after mount nfs root, this issue gone. So I'm closing this bug as NOTABUG. |