Michal, I checked the virtio_mem module and it's loaded - lsmod |grep virtio_mem virtio_mem 32768 0
And I can't make the actual value change to non-zerio. -> virsh update-memory pc --requested-size 256M or ->virsh setmem pc 1000M <memory model='virtio-mem'> <target> <size unit='KiB'>524288</size> <node>0</node> <block unit='KiB'>2048</block> <requested unit='KiB'>262144</requested> <actual unit='KiB'>0</actual> </target> <alias name='virtiomem0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memory> Any other suggestions ? > This is a bummer. What this represents is the actual value of membaloon. > Yes and no. It shows that we need <actual/> because guest might ignore > request to change the requested size. What you're probably experiencing > is that you haven't loaded virtio_mem module and thus the virtio-mem > device is ignoring requests for change (well, kernel is ignoring them, > whatever). On Thu, Feb 4, 2021 at 12:27 AM Michal Privoznik <mpriv...@redhat.com> wrote: > On 2/3/21 7:11 AM, Jing Qi wrote: > > I did some test for virtio-mem with libvirt upstream version > > v7.0.0-153-g5ea3ecd07d > > & qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64 > > > > S1. Start domain with memory device > > > > 1. Domain configuration- > > <maxMemory slots='16' unit='KiB'>10485760</maxMemory> > > <memory unit='KiB'>1572864</memory> > > <currentMemory unit='KiB'>1572864</currentMemory> > > ... > > <cpu mode='host-model' check='partial'> > > <numa> > > <cell id='0' cpus='0-3' memory='1048576' unit='KiB'/> > > </numa> > > </cpu> > > ... > > <memory model='virtio-mem'> > > <target> > > <size unit='KiB'>524288</size> > > <node>0</node> > > <block unit='KiB'>2048</block> > > <requested unit='KiB'>393216</requested> > > </target> > > <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' > > function='0x0'/> > > </memory> > > #virsh start pc > > Domain 'pc' started > > > > 2. The domain is started and check mem status, the actual size is > "1048576" > > #virsh dommemstat pc > > actual 1048576 > > This is a bummer. What this represents is the actual value of membaloon. > > > swap_in 0 > > swap_out 0 > > major_fault 257 > > minor_fault 130540 > > unused 604064 > > available 761328 > > usable 578428 > > last_update 1612325471 > > disk_caches 49632 > > hugetlb_pgalloc 0 > > hugetlb_pgfail 0 > > rss 460260 > > > > 3. Then, check the active xml - > > # virsh dumpxml pc > > ... > > <memory unit='KiB'>1572864</memory> > > <currentMemory unit='KiB'>1048576</currentMemory> > > .... > > <memory model='virtio-mem'> > > <target> > > <size unit='KiB'>524288</size> > > <node>0</node> > > <block unit='KiB'>2048</block> > > <requested unit='KiB'>393216</requested> > > <actual unit='KiB'>0</actual> > > </target> > > <alias name='virtiomem0'/> > > <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' > > function='0x0'/> > > </memory> > > > > Question1 : the value of actual is "0". Is it expected? > > Yes and no. It shows that we need <actual/> because guest might ignore > request to change the requested size. What you're probably experiencing > is that you haven't loaded virtio_mem module and thus the virtio-mem > device is ignoring requests for change (well, kernel is ignoring them, > whatever). > > > > > S2. Also, tried to use hugepage to start the domain - > > > > <memory model='virtio-mem'> > > <target> > > <size unit='KiB'>524288</size> > > <node>0</node> > > <block unit='KiB'>2048</block> > > <requested unit='KiB'>393216</requested> > > <actual unit='KiB'>0</actual> > > </target> > > <alias name='virtiomem0'/> > > <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' > > function='0x0'/> > > </memory> > > > > #virsh start pc > > error: Failed to start domain 'pc' > > error: internal error: process exited while connecting to monitor: > > 2021-02-03T05:50:33.157836Z qemu-system-x86_64: -object > > > memory-backend-file,id=memvirtiomem0,mem-path=/dev/hugepages/libvirt/qemu/9-pc,size=536870912,host-nodes=0,policy=bind: > > can't open backing store /dev/hugepages/libvirt/qemu/9-pc for guest RAM: > > Permission denied > > > > Question 2: any bug here? > > Ah, good catch! I'll fix this in v2. > > Michal > > -- Thanks & Regards, Jing,Qi