Bug 1897906
| Summary: | Enable suspending a VM with an NVDIMM device | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Nisim Simsolo <nsimsolo> | ||||||||
| Component: | BLL.Virt | Assignee: | Milan Zamazal <mzamazal> | ||||||||
| Status: | CLOSED DEFERRED | QA Contact: | meital avital <mavital> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 4.4.3.8 | CC: | ahadas, bugs, jinqi, nsimsolo | ||||||||
| Target Milestone: | --- | Flags: | pm-rhel:
ovirt-4.5?
|
||||||||
| 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: | 2022-04-13 07:35:41 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: | |||||||||||
| Bug Depends On: | 1902691, 1923905 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Nisim Simsolo
2020-11-15 14:05:01 UTC
Created attachment 1729522 [details]
qemu log
Created attachment 1729523 [details]
vdsm.log
Created attachment 1729524 [details]
engine.log
It works for me, with a much more smaller NVDIMM (~5 GB) than yours (~256 GB). Saving state takes about half minute for my fully emulated device. I can see in the attached logs that it's still saving state after more than hour in your case. There is no relevant error and no end. Nisim, what NVDIMM modes did you use on the host and in the guest? And it is a hardware device, right? How long did you actually wait? Would it be possible to retest with fsdax and devdax modes (the latter requires switching SELinux to permissive mode)? I think it would be interesting to see if it happens with those modes too. > Nisim, what NVDIMM modes did you use on the host and in the guest? And it is > a hardware device, right? HW device, in devdax mode. > How long did you actually wait? more than 2 hours > Would it be possible to retest with fsdax and devdax modes (the latter requires > switching SELinux to permissive mode)? I think it would be interesting to > see if it happens with those modes too. Yes, I will update you with the outcome. Nisim, did you have a chance to test with the different modes already? (In reply to Milan Zamazal from comment #6) > Nisim, did you have a chance to test with the different modes already? Yes, it behaves the same when using fsdax and devdax (with permissive SELinux) Thanks for testing, a QEMUÂ bug filed: https://bugzilla.redhat.com/1902691 Let's disable suspending VMs with NVDIMMs for now, see Bug 1912426. We will handle this bug and enable suspending VMs with NVDIMMs again once a platform fix is available. Verified with libvirt upstream code version v7.0.0-rc1
& qemu-kvm-5.1.0-17.module+el8.3.1+9213+7ace09c3.x86_64
Start vm with below xml -
<memory model='nvdimm' access='shared'>
<source>
<path>/dev/dax0.0</path>
<alignsize unit='KiB'>2048</alignsize>
<pmem/>
</source>
<target>
<size unit='KiB'>262144000</size>
<node>0</node>
<label>
<size unit='KiB'>128</size>
</label>
</target>
<address type='dimm' slot='0'/>
</memory>
From the qemu-cmd line, there is no "prealloc" and there is no long waiting time when issuing "start vm" command.
-object memory-backend-file,id=memnvdimm0,mem-path=/dev/dax0.0,share=yes,size=268435456000,align=2097152,pmem=yes -device nvdimm,node=0,label-size=131072,memdev=memnvdimm0,id=nvdimm0,slot=0
The bot shouldn't change the status just because a bug is mentioned anywhere in the commit message... Closing since the platform bugs have not been prioritized for el8 If we upgrade to el9 and the depended platform bugs are resolved, we should do that |