Bug 1836043 - Please switch to '-M memory-backend' when using hugepage as backend
Summary: Please switch to '-M memory-backend' when using hugepage as backend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.3
Assignee: Michal Privoznik
QA Contact: Jing Qi
URL:
Whiteboard:
Depends On: 1912201
Blocks: 1897025
TreeView+ depends on / blocked
 
Reported: 2020-05-15 02:20 UTC by Yumei Huang
Modified: 2021-05-25 06:42 UTC (History)
14 users (show)

Fixed In Version: libvirt-6.10.0-1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-25 06:42:08 UTC
Type: Bug
Target Upstream Version: 6.9.0


Attachments (Terms of Use)
source qemu command file (2.18 KB, text/plain)
2020-12-15 03:18 UTC, Jing Qi
no flags Details
target qemu command file (2.11 KB, text/plain)
2020-12-15 03:19 UTC, Jing Qi
no flags Details

Description Yumei Huang 2020-05-15 02:20:15 UTC
Description of problem:

If use below xml snippet, 

<memoryBacking>
<hugepages/>
</memoryBacking>

the corresponding qemu cli is:

-mem-prealloc \
-mem-path /dev/hugepages/libvirt/qemu/1-rhel8 


In qemu5.0, -mem-path and -mem-prealloc are aliased to '-M memory-backend' internally. So we request libvirt to make a change to use '-M memory-backend'.


The usage of '-M memory-backend' is like this,

# /usr/libexec/qemu-kvm \
  -m 4G \
  -object memory-backend-file,mem-path=/dev/hugepages/libvirt/qemu/1-rhel8 ,size=4G,id=mem0,prealloc=yes \
  -M q35,memory-backend=mem0



Version-Release number of selected component (if applicable):
libvirt-client-6.3.0-1.module+el8.3.0+6478+69f490bb.x86_64
qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jaroslav Suchanek 2020-05-18 13:33:23 UTC
Miso, was this already discussed upstream? Is it something we should prioritize? Thanks.

Comment 2 Michal Privoznik 2020-05-18 13:55:24 UTC
Writing the code is not a problem, but question is whether QEMU is able to migrate if the source uses the old command line and the destination would use the new command line. Also, is there any specific reason why the command line generated by libvirt is not good (I mean apart from aliasing)? I will need to check whether this new mode is somehow detectable through QMP so that libvirt knows whether QEMU supports the new mode or not.

Comment 3 Yumei Huang 2020-05-19 01:44:13 UTC
(In reply to Michal Privoznik from comment #2)
> Writing the code is not a problem, but question is whether QEMU is able to
> migrate if the source uses the old command line and the destination would
> use the new command line. 

No, migration would fail if source and destination use different command line. I guess it's in the same situation as https://www.redhat.com/archives/libvir-list/2020-May/msg00490.html.

> Also, is there any specific reason why the command
> line generated by libvirt is not good (I mean apart from aliasing)? 

I will leave this question to our QEMU developer Igor who introduced memory-backend property.

Igor, would you please help explain? Thanks.

> I will
> need to check whether this new mode is somehow detectable through QMP so
> that libvirt knows whether QEMU supports the new mode or not.

Comment 4 Igor Mammedov 2020-05-19 11:49:05 UTC
I'd like mem-prealloc and mem-path CLI to be deprecated and eventually removed,
everything they are doing can be accomplished with new memory-backend property.

As for migration, old and new way can be compatible, in case mem-path was used 
one should replace it with memory-backend-file object, and mem-prealloc is replaced
by corresponding 'prealloc' property. One thing that's not available to libvirt
is MachineClass::default_ram_id to keep migration stream compatible.

'id' isn't going to change ever (to keep migration working) so it could be
hardcoded on libvirt side (typically each machine has its own id) or as
an alternative, I can make a patch to expose it via query-machines.

Another reason for supporting memory-backend is virtfs use-case (which requires
file/fd backend) without using '-numa memdev' hack where numa is available
and in-case of s390 (which lacks numa) memory-backend is the only way to use
virtiofs.

Comment 5 Michal Privoznik 2020-05-25 16:36:00 UTC
(In reply to Igor Mammedov from comment #4)
> I'd like mem-prealloc and mem-path CLI to be deprecated and eventually
> removed,
> everything they are doing can be accomplished with new memory-backend
> property.
> 
> As for migration, old and new way can be compatible, in case mem-path was
> used 
> one should replace it with memory-backend-file object, and mem-prealloc is
> replaced
> by corresponding 'prealloc' property. One thing that's not available to
> libvirt
> is MachineClass::default_ram_id to keep migration stream compatible.

Yeah, this is what I just hit in my testing. I wrote some patches and tested migration. If the id was random string (say "ram0"), then migration did not work. But if I changed it to "pc.ram" then it suddenly started working. I was able to migrate to even older QEMU which didn't have -machine memory-backend= support. Is this expected? Looking into gitlog, the name was introduced in v0.13.0-rc0~96 and kept unchanged (because as you say it would break migration).

> 
> 'id' isn't going to change ever (to keep migration working) so it could be
> hardcoded on libvirt side (typically each machine has its own id) or as
> an alternative, I can make a patch to expose it via query-machines.

Yeah, that could work. Libvirt can use it then to detect whether the -machine memory-backend= is supported or not. There is going to be one release of QEMU where it is supported and libvirt would still use the old cmd line, but I think that's acceptable.

> 
> Another reason for supporting memory-backend is virtfs use-case (which
> requires
> file/fd backend) without using '-numa memdev' hack where numa is available
> and in-case of s390 (which lacks numa) memory-backend is the only way to use
> virtiofs.

Yeah, my idea is to make the switch complete. I mean, not only use memory-backend-file instead of -mem-path but use memory-backend-ram for regular case. That simplifies implementation on libvirt side and possibly allows you to deprecate more stuff.

Comment 7 Michal Privoznik 2020-09-01 10:01:37 UTC
Rebased patches sent to the list (now that QEMU part is merged):

https://www.redhat.com/archives/libvir-list/2020-September/msg00023.html

Comment 9 Michal Privoznik 2020-10-01 10:14:24 UTC
Merged upstream as:

88957116c9 qemu: Use memory-backend-* for regular guest memory
b647654cbb qemu: Track default-ram-id machine attribute
d1ffc8cd3e qemuBuildMemoryBackendProps: Fix const correctness
a658a4bdf7 qemuBuildMemoryBackendProps: Prealloc mem for memfd backend
0217c5a6b4 qemuBuildMemoryBackendProps: Respect //memoryBacking/allocation/@mode=immediate
eda5cc7a62 qemuBuildMemoryBackendProps: Move @prealloc setting to backend agnostic part

v6.8.0-27-g88957116c9

Comment 11 Michal Privoznik 2020-10-06 08:04:02 UTC
We will need this patch too:

https://www.redhat.com/archives/libvir-list/2020-October/msg00400.html

Comment 12 Michal Privoznik 2020-10-08 10:57:58 UTC
Pushed upstream as:

0c8ab47847 qemu: Don't generate '-machine memory-backend' and '-numa memdev'

v6.8.0-232-g0c8ab47847

Comment 13 Michal Privoznik 2020-12-01 12:57:32 UTC
Moving to POST per comment 12.

Comment 14 Jing Qi 2020-12-14 09:08:31 UTC
Tested with libvirt-daemon-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64 & 
qemu-kvm-5.2.0-0.module+el8.4.0+8855+a9e237a9.x86_64

S1: Start vm with hugepages and without numa node configuration in xml
step:
1. the domain xml include below xml part  -
 <memoryBacking>
    <hugepages>
      <page size='2048' unit='KiB'/>
    </hugepages>
    <source type='memfd'/>
    <allocation mode='immediate'/>
  </memoryBacking>


  and there is NO numa cell configuration.

2. Start vm and check the qemu-kvm cmdline

 <memoryBacking>
    <hugepages>
      <page size='2048' unit='KiB'/>
    </hugepages>
    <source type='memfd'/>
    <allocation mode='immediate'/>
  </memoryBacking>

-machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram \
-cpu IvyBridge-IBRS,ss=on,pcid=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,ibpb=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-vapic,hv-spinlocks=0x1000 \
-m 2560 \
-object memory-backend-memfd,id=pc.ram,hugetlb=yes,hugetlbsize=2097152,prealloc=yes,size=2684354560 \

Result:

The memory-backend is used instead of "-mem-prealloc -mem-path" .

s2: Migrate the vm to libvirt-daemon-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64 & 
qemu-kvm-5.2.0-0.module+el8.4.0+8855+a9e237a9.x86_64
virsh migrate rhel8 qemu+ssh://10.73.xx.xx/system --live --verbose 
root@10.73.xx.xx's password: 
Migration: [100 %]

s3: Migrate the vm with the same domain xml configuration from 8.3 to 8.4
libvirt-daemon-6.6.0-9.module+el8.3.1+9131+fb7f8c9f.x86_64 & qemu-kvm-5.1.0-16.module+el8.3.1+8958+410ab178.x86_64

# virsh migrate rhel8 qemu+ssh://10.73.xx.xx/system --live --verbose --unsafe
root@10.73.xx.xx's password: 
error: internal error: qemu unexpectedly closed the monitor: 2020-12-14T09:05:25.349045Z qemu-kvm: -device cirrus-vga,id=video0,bus=pci.0,addr=0x2: warning: 'cirrus-vga' is deprecated, please use a different VGA card instead
2020-12-14T09:05:25.669997Z qemu-kvm: Unknown ramblock "pc.ram", cannot accept migration
2020-12-14T09:05:25.670041Z qemu-kvm: error while loading state for instance 0x0 of device 'ram'
2020-12-14T09:05:25.670457Z qemu-kvm: load of migration failed: Invalid argument

Michal, could you please help to confirm if it's accepted for s3, Thanks!

Comment 15 Michal Privoznik 2020-12-14 10:54:37 UTC
I think we need Igor's opinion.

Comment 16 Igor Mammedov 2020-12-14 11:30:32 UTC
(In reply to Jing Qi from comment #14)
> Tested with libvirt-daemon-6.10.0-1.module+el8.4.0+8898+a84e86e1.x86_64 & 
> qemu-kvm-5.2.0-0.module+el8.4.0+8855+a9e237a9.x86_64
> 
> S1: Start vm with hugepages and without numa node configuration in xml
> step:
> 1. the domain xml include below xml part  -
>  <memoryBacking>
>     <hugepages>
>       <page size='2048' unit='KiB'/>
>     </hugepages>
>     <source type='memfd'/>
>     <allocation mode='immediate'/>
>   </memoryBacking>
> 
> 
>   and there is NO numa cell configuration.
> 
> 2. Start vm and check the qemu-kvm cmdline
> 
>  <memoryBacking>
>     <hugepages>
>       <page size='2048' unit='KiB'/>
>     </hugepages>
>     <source type='memfd'/>
>     <allocation mode='immediate'/>
>   </memoryBacking>
> 
> -machine
> pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.
> ram \
> -cpu
> IvyBridge-IBRS,ss=on,pcid=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-
> clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,
> ibpb=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-
> time,hv-vapic,hv-spinlocks=0x1000 \
> -m 2560 \
> -object
> memory-backend-memfd,id=pc.ram,hugetlb=yes,hugetlbsize=2097152,prealloc=yes,
> size=2684354560 \
> 
[...]
> 
> s3: Migrate the vm with the same domain xml configuration from 8.3 to 8.4
> libvirt-daemon-6.6.0-9.module+el8.3.1+9131+fb7f8c9f.x86_64 &
> qemu-kvm-5.1.0-16.module+el8.3.1+8958+410ab178.x86_64
> 
> # virsh migrate rhel8 qemu+ssh://10.73.xx.xx/system --live --verbose --unsafe
> root@10.73.xx.xx's password: 
> error: internal error: qemu unexpectedly closed the monitor:
> 2020-12-14T09:05:25.349045Z qemu-kvm: -device
> cirrus-vga,id=video0,bus=pci.0,addr=0x2: warning: 'cirrus-vga' is
> deprecated, please use a different VGA card instead
> 2020-12-14T09:05:25.669997Z qemu-kvm: Unknown ramblock "pc.ram", cannot
> accept migration
> 2020-12-14T09:05:25.670041Z qemu-kvm: error while loading state for instance
> 0x0 of device 'ram'
> 2020-12-14T09:05:25.670457Z qemu-kvm: load of migration failed: Invalid
> argument
> 
> Michal, could you please help to confirm if it's accepted for s3, Thanks!
I'd say it should work,
what was target qemu CLI in this case?

Comment 17 Michal Privoznik 2020-12-14 16:46:16 UTC
I've just did some quick check and I was able to migrate current libvirt and qemu with default RAM id and without it. I mean, back and forth between:

-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \
-cpu qemu64 \
-m 4096 \
-object memory-backend-ram,id=pc.ram,size=4294967296 \

and

-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu qemu64,x2apic=on,hypervisor=on,lahf-lm=on,svm=off \
-m 4096 \


libvirt: v6.10.0-206-gbff2ad5d6b
qemu: v5.2.0-329-g17584289af

Jing, can you share your command lines from the source and the destination?

Comment 18 Jing Qi 2020-12-15 03:18:53 UTC
Created attachment 1739218 [details]
source qemu command file

Comment 19 Jing Qi 2020-12-15 03:19:41 UTC
Created attachment 1739219 [details]
target qemu command file

Comment 20 Jing Qi 2020-12-15 03:23:37 UTC
I used "pc-i440fx-rhel7.6.0" for the testing since there is a virtio-blk issue currently for "q35" machine.
And the target and source qemu command files were uploaded.

Comment 21 Michal Privoznik 2020-12-15 07:50:25 UTC
Ah, forgot about the memfd. I've used regular pages. Anyway, retested and these are the interesting bits from source and destination:

-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \
-cpu qemu64 \
-m 4096 \
-object memory-backend-memfd,id=pc.ram,hugetlb=yes,hugetlbsize=2097152,prealloc=yes,size=4294967296 \

-machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu qemu64,x2apic=on,hypervisor=on,lahf-lm=on,svm=off \
-m 4096 \
-mem-prealloc \
-mem-path /hugepages2M/libvirt/qemu/4-fedora30 \


(yes, I know on the destination libvirt did not use memfd because of bug 1839034)

But anyway, I was able to migrate there and back successfully. Igor, got any clues?

Comment 22 Igor Mammedov 2020-12-16 12:33:34 UTC
Jing,


does adding 'x-use-canonical-path-for-ramblock-id=off' option to backend on target helps?

Comment 24 Jing Qi 2020-12-21 05:49:43 UTC
Igor, Yes. With adding 'x-use-canonical-path-for-ramblock-id=off', the migration can succeed.

source qemu cmd:
/usr/libexec/qemu-kvm -name guest=rhel8,debug-threads=on -S -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge-IBRS,ss=on,pcid=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,ibpb=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-vapic,hv-spinlocks=0x1000 -m 2560 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu/1-rhel8 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 60d7e03d-0d7b-42c6-ac4c-4da98dd6a5ec -display none -no-user-config -nodefaults -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -blockdev '{"driver":"file","filename":"/nfs/RHEL-8.4-x86_64-latest.qcow2","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' -device ide-hd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,bootindex=1,write-cache=on -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -monitor stdio

target qemu cmd:
/usr/libexec/qemu-kvm -name guest=rhel8,debug-threads=on -S -machine pc-i440fx-rhel7.6.0,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram -cpu IvyBridge-IBRS,ss=on,pcid=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,ibpb=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-vapic,hv-spinlocks=0x1000 -m 2560 -object memory-backend-file,id=pc.ram,mem-path=/dev/hugepages/libvirt/qemu/10-rhel8,prealloc=yes,size=2684354560,x-use-canonical-path-for-ramblock-id=off -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 60d7e03d-0d7b-42c6-ac4c-4da98dd6a5ec -display none -no-user-config -nodefaults -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -blockdev '{"driver":"file","filename":"/nfs/RHEL-8.4-x86_64-latest.qcow2","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' -device ide-hd,bus=ide.0,unit=0,drive=libvirt-1-format,id=ide0-0-0,bootindex=1,write-cache=on -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on -incoming defer -monitor stdio

Comment 26 Igor Mammedov 2020-12-31 17:53:11 UTC
Looks like we broke compat machinery somehow when moved to qemu-5.2
CCing David.

PS:
issue needs it's own BZ

Comment 27 Jing Qi 2021-01-04 04:04:39 UTC
(In reply to Igor Mammedov from comment #26)
> Looks like we broke compat machinery somehow when moved to qemu-5.2
> CCing David.
> 
> PS:
> issue needs it's own BZ
  
Filed new bug 1912201 for it .

Comment 30 Igor Mammedov 2021-01-07 18:28:03 UTC
Duplicating comment https://bugzilla.redhat.com/show_bug.cgi?id=1912201#c10 here"

Issue is that when
 -machine memory-backend=pc.ram \
 -object memory-backend-memfd,id=pc.ram
created backend may change MemoryRegion name to canonical one that adds '/object/' to 'id',
when compat property is set to 'x-use-canonical-path-for-ramblock-id=on'.

so for old machine types where 'x-use-canonical-path-for-ramblock-id=on', -object creates
backend with MemoryRegion 'id' that contains '/object/' in it, hen migration fails
as old target QEMU or QEMU started without -machine memory-backend expect prefix-less
'id' in migration stream.

It's possible to fix on libvirt side by always adding 'x-use-canonical-path-for-ramblock-id=off' 
to to the backend that will be used with -machine memory-backend.
(That's what legacy -m X, does under hood, note x-use-canonical-path-for-ramblock-id option is
available since qemu-4.0)

Another alternative could be not using '-machine memory-backend' for machines older than
upstream 4.0 and downstream rhel8.0.

Comment 31 Igor Mammedov 2021-01-07 19:15:03 UTC
Basically if QEMU supports '-machine memory-backend',
then always feed it backend with 'x-use-canonical-path-for-ramblock-id=off' option.

Comment 32 Michal Privoznik 2021-01-08 09:10:30 UTC
(In reply to Igor Mammedov from comment #31)
> Basically if QEMU supports '-machine memory-backend',
> then always feed it backend with 'x-use-canonical-path-for-ramblock-id=off'
> option.

The way I read qemu code it's necessary to set only if memory-backend-memfd/memory-backend-file is a replacement for '-m X', right? For other cases, it should not be set, right? For instance NUMA: -numa nome,memdev=$ID -object memory-backend-memfd,id=$ID.

If it is so, then it should be fairly simple to implement. But it feels a bit hackish.

Comment 33 Igor Mammedov 2021-01-08 09:38:54 UTC
(In reply to Michal Privoznik from comment #32)
> (In reply to Igor Mammedov from comment #31)
> > Basically if QEMU supports '-machine memory-backend',
> > then always feed it backend with 'x-use-canonical-path-for-ramblock-id=off'
> > option.
> 
> The way I read qemu code it's necessary to set only if
> memory-backend-memfd/memory-backend-file is a replacement for '-m X', right?
yes, only for a backend that will be used with '-machine memory-backend'

reason for that is that MemoryRegion backend is replacing doesn't use any
prefix.

> For other cases, it should not be set, right? For instance NUMA: -numa
> nome,memdev=$ID -object memory-backend-memfd,id=$ID.
> 
> If it is so, then it should be fairly simple to implement. But it feels a
> bit hackish.

it's looks like that, but there is literally nothing we can do about it on QEMU side,
since backend is provided by user. option is necessary only for keeping migration
working for old machine types (before 4.0/rhel76). For newer machine
types it's no necessary since it's 'off' by default.

I'll post a patch to update '-machine memory-backend' doc comment, so it
would mention this caveat.

Comment 34 Peter Krempa 2021-01-08 15:03:33 UTC
If libvirt is required to use a property with the 'x-' prefix (As I understand there isn't any other option to keep compatibility with older versions otherwise) we'll need some form of guarantee that the 'x-' prefixed parameter will not be modified in the future. By guarantee I mean adding documentation and code comment which state that this is considered stable regardless of the 'x-' policy used for other properties. That way we'll be able to waive the requirement that no 'x-' prefixed stuff is used in libvirt.

Comment 35 Igor Mammedov 2021-01-08 18:34:16 UTC
(In reply to Peter Krempa from comment #34)
> If libvirt is required to use a property with the 'x-' prefix (As I
> understand there isn't any other option to keep compatibility with older
> versions otherwise) we'll need some form of guarantee that the 'x-' prefixed
> parameter will not be modified in the future. By guarantee I mean adding
> documentation and code comment which state that this is considered stable
> regardless of the 'x-' policy used for other properties. That way we'll be
> able to waive the requirement that no 'x-' prefixed stuff is used in libvirt.

sure, I'll post a patch.

Michal,

x-use-canonical-path-for-ramblock-id is only applicable to
memory-backend-memfd/memory-backend-file.

Comment 36 Michal Privoznik 2021-01-15 09:31:01 UTC
Since we still have a serious blocker (bug 1912201) I'm moving this back to ASSIGNED. The feature is unusable until the blocker is fixed.

Comment 39 Michal Privoznik 2021-02-11 09:00:46 UTC
The problem mentioned in comment 36 was fixed upstream. Moving back to ON_QA.

Comment 41 Jing Qi 2021-02-22 09:20:34 UTC
Verified with version - 

libvirt-7.0.0-4.module+el8.4.0+10093+e085f1eb.x86_64 & qemu-kvm-5.2.0-5.module+el8.4.0+9775+0937c167.x86_64

The test steps are included in comment 14 above (S1 & S2) and comment 24 (S3) in bug 1912201

Comment 44 errata-xmlrpc 2021-05-25 06:42:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:2098


Note You need to log in before you can comment on or make changes to this bug.