[ovirt-users] hot plug memory in el7
Nathanaël Blanchet
blanchet at abes.fr
Thu Dec 10 10:31:56 UTC 2015
Le 10/12/2015 10:41, Michal Skrivanek a écrit :
>
>> On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi at gmail.com
>> <mailto:gianluca.cecchi at gmail.com>> wrote:
>>
>> On Wed, Dec 9, 2015 at 10:21 PM, Sandro Bonazzola wrote:
>>
>>
>>
>> No idea. If it's libvirt issue, can you test
>> http://cbs.centos.org/koji/buildinfo?buildID=4726 ? it's from
>> centos virt sig, introduced for Xen but should work on kvm as
>> well. or the 7.2 libvirt from
>> http://mirror.centos.org/centos/7/cr/x86_64/Packages/.
>>
>>
>>
>> Hello,
>> tried on a test environment where I have 3.6.0 on single CentOS 7.1
>> hypervisor configured with SelfHostedEngine
>> I have a CentOS 7.1 vm running.
>>
>> On hypervisor I shutdown VM, put maintenance global and shutdown
>> engine VM.
>> Then
>> [root at ractor ~]# yum --enablerepo=cr update libvirt*
>> Loaded plugins: fastestmirror, langpacks
>> cr | 3.4 kB 00:00:00
>> cr/7/x86_64/primary_db | 3.7 MB 00:00:02
>> Loading mirror speeds from cached hostfile
>> * base: centos.fastbull.org <http://centos.fastbull.org/>
>> * extras: centos.fastbull.org <http://centos.fastbull.org/>
>> * ovirt-3.6: ftp.nluug.nl <http://ftp.nluug.nl/>
>> * ovirt-3.6-epel: epel.besthosting.ua <http://epel.besthosting.ua/>
>> * updates: centos.copahost.com <http://centos.copahost.com/>
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package libvirt-client.x86_64 0:1.2.8-16.el7_1.5 will be updated
>> ---> Package libvirt-client.x86_64 0:1.2.17-13.el7_2.2 will be an update
>> --> Processing Dependency: libsystemd.so.0(LIBSYSTEMD_209)(64bit) for
>> package: libvirt-client-1.2.17-13.el7_2.2.x86_64
>> --> Processing Dependency: libsystemd.so.0()(64bit) for package:
>> libvirt-client-1.2.17-13.el7_2.2.x86_64
>> ---> Package libvirt-daemon.x86_64 0:1.2.8-16.el7_1.5 will be updated
>> ---> Package libvirt-daemon.x86_64 0:1.2.17-13.el7_2.2 will be an update
>> ---> Package libvirt-daemon-config-nwfilter.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-config-nwfilter.x86_64
>> 0:1.2.17-13.el7_2.2 will be an update
>> ---> Package libvirt-daemon-driver-interface.x86_64
>> 0:1.2.8-16.el7_1.5 will be updated
>> ---> Package libvirt-daemon-driver-interface.x86_64
>> 0:1.2.17-13.el7_2.2 will be an update
>> ---> Package libvirt-daemon-driver-network.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-network.x86_64 0:1.2.17-13.el7_2.2
>> will be an update
>> ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.17-13.el7_2.2
>> will be an update
>> ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-nwfilter.x86_64
>> 0:1.2.17-13.el7_2.2 will be an update
>> ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.2.17-13.el7_2.2
>> will be an update
>> ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.17-13.el7_2.2
>> will be an update
>> ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.8-16.el7_1.5
>> will be updated
>> ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.17-13.el7_2.2
>> will be an update
>> --> Processing Dependency: libdevmapper.so.1.02(DM_1_02_97)(64bit)
>> for package: libvirt-daemon-driver-storage-1.2.17-13.el7_2.2.x86_64
>> ---> Package libvirt-daemon-kvm.x86_64 0:1.2.8-16.el7_1.5 will be updated
>> ---> Package libvirt-daemon-kvm.x86_64 0:1.2.17-13.el7_2.2 will be an
>> update
>> ---> Package libvirt-lock-sanlock.x86_64 0:1.2.8-16.el7_1.5 will be
>> updated
>> ---> Package libvirt-lock-sanlock.x86_64 0:1.2.17-13.el7_2.2 will be
>> an update
>> ---> Package libvirt-python.x86_64 0:1.2.8-7.el7_1.1 will be updated
>> ---> Package libvirt-python.x86_64 0:1.2.17-2.el7 will be an update
>> --> Running transaction check
>> ---> Package device-mapper-libs.x86_64 7:1.02.93-3.el7_1.1 will be
>> updated
>> --> Processing Dependency: device-mapper-libs = 7:1.02.93-3.el7_1.1
>> for package: 7:device-mapper-1.02.93-3.el7_1.1.x86_64
>> ---> Package device-mapper-libs.x86_64 7:1.02.107-5.el7 will be an update
>> ---> Package systemd-libs.x86_64 0:208-20.el7_1.6 will be updated
>> --> Processing Dependency: systemd-libs = 208-20.el7_1.6 for package:
>> systemd-208-20.el7_1.6.x86_64
>> ---> Package systemd-libs.x86_64 0:219-19.el7 will be an update
>> --> Running transaction check
>> ---> Package device-mapper.x86_64 7:1.02.93-3.el7_1.1 will be updated
>> --> Processing Dependency: device-mapper = 7:1.02.93-3.el7_1.1 for
>> package: 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64
>> ---> Package device-mapper.x86_64 7:1.02.107-5.el7 will be an update
>> ---> Package systemd.x86_64 0:208-20.el7_1.6 will be updated
>> --> Processing Dependency: systemd = 208-20.el7_1.6 for package:
>> systemd-sysv-208-20.el7_1.6.x86_64
>> --> Processing Dependency: systemd = 208-20.el7_1.6 for package:
>> systemd-python-208-20.el7_1.6.x86_64
>> --> Processing Dependency: systemd = 208-20.el7_1.6 for package:
>> libgudev1-208-20.el7_1.6.x86_64
>> ---> Package systemd.x86_64 0:219-19.el7 will be an update
>> --> Processing Dependency: kmod >= 18-4 for package:
>> systemd-219-19.el7.x86_64
>> --> Running transaction check
>> ---> Package device-mapper-event.x86_64 7:1.02.93-3.el7_1.1 will be
>> updated
>> --> Processing Dependency: device-mapper-event = 7:1.02.93-3.el7_1.1
>> for package: 7:lvm2-libs-2.02.115-3.el7_1.1.x86_64
>> ---> Package device-mapper-event.x86_64 7:1.02.107-5.el7 will be an
>> update
>> --> Processing Dependency: device-mapper-event-libs =
>> 7:1.02.107-5.el7 for package: 7:device-mapper-event-1.02.107-5.el7.x86_64
>> ---> Package kmod.x86_64 0:14-10.el7 will be updated
>> ---> Package kmod.x86_64 0:20-5.el7 will be an update
>> ---> Package libgudev1.x86_64 0:208-20.el7_1.6 will be updated
>> ---> Package libgudev1.x86_64 0:219-19.el7 will be an update
>> ---> Package systemd-python.x86_64 0:208-20.el7_1.6 will be updated
>> ---> Package systemd-python.x86_64 0:219-19.el7 will be an update
>> ---> Package systemd-sysv.x86_64 0:208-20.el7_1.6 will be updated
>> ---> Package systemd-sysv.x86_64 0:219-19.el7 will be an update
>> --> Running transaction check
>> ---> Package device-mapper-event-libs.x86_64 7:1.02.93-3.el7_1.1 will
>> be updated
>> ---> Package device-mapper-event-libs.x86_64 7:1.02.107-5.el7 will be
>> an update
>> ---> Package lvm2-libs.x86_64 7:2.02.115-3.el7_1.1 will be updated
>> --> Processing Dependency: lvm2-libs = 7:2.02.115-3.el7_1.1 for
>> package: 7:lvm2-2.02.115-3.el7_1.1.x86_64
>> ---> Package lvm2-libs.x86_64 7:2.02.130-5.el7 will be an update
>> --> Running transaction check
>> ---> Package lvm2.x86_64 7:2.02.115-3.el7_1.1 will be updated
>> ---> Package lvm2.x86_64 7:2.02.130-5.el7 will be an update
>> --> Processing Dependency: device-mapper-persistent-data >= 0.5.5-1
>> for package: 7:lvm2-2.02.130-5.el7.x86_64
>> --> Running transaction check
>> ---> Package device-mapper-persistent-data.x86_64 0:0.4.1-2.el7 will
>> be updated
>> ---> Package device-mapper-persistent-data.x86_64 0:0.5.5-1.el7 will
>> be an update
>> --> Processing Conflict: systemd-219-19.el7.x86_64 conflicts
>> initscripts < 9.49.28-1
>> --> Restarting Dependency Resolution with new changes.
>> --> Running transaction check
>> ---> Package initscripts.x86_64 0:9.49.24-1.el7 will be updated
>> ---> Package initscripts.x86_64 0:9.49.30-1.el7 will be an update
>> --> Processing Conflict: systemd-219-19.el7.x86_64 conflicts dracut <
>> 033-243
>> --> Restarting Dependency Resolution with new changes.
>> --> Running transaction check
>> ---> Package dracut.x86_64 0:033-241.el7_1.5 will be updated
>> --> Processing Dependency: dracut = 033-241.el7_1.5 for package:
>> dracut-config-rescue-033-241.el7_1.5.x86_64
>> --> Processing Dependency: dracut = 033-241.el7_1.5 for package:
>> dracut-network-033-241.el7_1.5.x86_64
>> ---> Package dracut.x86_64 0:033-360.el7_2 will be an update
>> --> Running transaction check
>> ---> Package dracut-config-rescue.x86_64 0:033-241.el7_1.5 will be
>> updated
>> ---> Package dracut-config-rescue.x86_64 0:033-360.el7_2 will be an
>> update
>> ---> Package dracut-network.x86_64 0:033-241.el7_1.5 will be updated
>> ---> Package dracut-network.x86_64 0:033-360.el7_2 will be an update
>> --> Finished Dependency Resolution
>>
>> Dependencies Resolved
>>
>> ====================================================================================================
>> Package Arch
>> Version Repository Size
>> ====================================================================================================
>> Updating:
>> dracut x86_64
>> 033-360.el7_2 cr 311 k
>> initscripts x86_64
>> 9.49.30-1.el7 cr 429 k
>> libvirt-client x86_64
>> 1.2.17-13.el7_2.2 cr 4.3 M
>> libvirt-daemon x86_64
>> 1.2.17-13.el7_2.2 cr 584 k
>> libvirt-daemon-config-nwfilter x86_64
>> 1.2.17-13.el7_2.2 cr 121 k
>> libvirt-daemon-driver-interface x86_64
>> 1.2.17-13.el7_2.2 cr 161 k
>> libvirt-daemon-driver-network x86_64
>> 1.2.17-13.el7_2.2 cr 301 k
>> libvirt-daemon-driver-nodedev x86_64
>> 1.2.17-13.el7_2.2 cr 160 k
>> libvirt-daemon-driver-nwfilter x86_64
>> 1.2.17-13.el7_2.2 cr 184 k
>> libvirt-daemon-driver-qemu x86_64
>> 1.2.17-13.el7_2.2 cr 569 k
>> libvirt-daemon-driver-secret x86_64
>> 1.2.17-13.el7_2.2 cr 154 k
>> libvirt-daemon-driver-storage x86_64
>> 1.2.17-13.el7_2.2 cr 327 k
>> libvirt-daemon-kvm x86_64
>> 1.2.17-13.el7_2.2 cr 117 k
>> libvirt-lock-sanlock x86_64
>> 1.2.17-13.el7_2.2 cr 166 k
>> libvirt-python x86_64
>> 1.2.17-2.el7 cr 309 k
>> Updating for dependencies:
>> device-mapper x86_64
>> 7:1.02.107-5.el7 cr 251 k
>> device-mapper-event x86_64
>> 7:1.02.107-5.el7 cr 167 k
>> device-mapper-event-libs x86_64
>> 7:1.02.107-5.el7 cr 169 k
>> device-mapper-libs x86_64
>> 7:1.02.107-5.el7 cr 304 k
>> device-mapper-persistent-data x86_64
>> 0.5.5-1.el7 cr 350 k
>> dracut-config-rescue x86_64
>> 033-360.el7_2 cr 49 k
>> dracut-network x86_64
>> 033-360.el7_2 cr 90 k
>> kmod x86_64
>> 20-5.el7 cr 114 k
>> libgudev1 x86_64
>> 219-19.el7 cr 64 k
>> lvm2 x86_64
>> 7:2.02.130-5.el7 cr 1.0 M
>> lvm2-libs x86_64
>> 7:2.02.130-5.el7 cr 872 k
>> systemd x86_64
>> 219-19.el7 cr 5.1 M
>> systemd-libs x86_64
>> 219-19.el7 cr 356 k
>> systemd-python x86_64
>> 219-19.el7 cr 97 k
>> systemd-sysv x86_64
>> 219-19.el7 cr 52 k
>>
>> Transaction Summary
>> ====================================================================================================
>> Upgrade 15 Packages (+15 Dependent packages)
>>
>> Total download size: 17 M
>> Is this ok [y/d/N]:
>>
>> Then I reboot my HV, exit from maintenance, connect to engine and
>> start VM.
>> VM situation
>> $ free
>> total used free shared buff/cache
>> available
>> Mem: 8172900 147356 7875692 8480 149852 7847248
>> Swap: 839676 0 839676
>>
>> I set memory from 8192Mb to 10240Mb
>> I get the same window I got with previous libvirt version.
>> I select OK (I don't select "Apply later" checkbox)
>>
>> Inside guest there is no changed memory, but I can see this in
>> /var/log/messages:
>
> could it be perhaps the guest has troubles recognizing hotplug? Is it
> also a CentOS 7.1 guest?
>
>>
>> Dec 9 23:56:18 racclient1 kernel: init_memory_mapping: [mem
>> 0x240000000-0x2bfffffff]
>>
>> ANd output of dmesg contains:
>>
>> [ 219.363640] ACPI: \_SB_.MP00: ACPI_NOTIFY_DEVICE_CHECK event
>> [ 219.364248] init_memory_mapping: [mem 0x240000000-0x2bfffffff]
>> [ 219.364253] [mem 0x240000000-0x2bfffffff] page 2M
>> [ 219.366773] [ffffea0009000000-ffffea00091fffff] PMD ->
>> [ffff8800b7e00000-ffff8800b7ffffff] on node 0
>> [ 219.368433] [ffffea0009200000-ffffea00093fffff] PMD ->
>> [ffff880231400000-ffff8802315fffff] on node 0
>> [ 219.369838] [ffffea0009400000-ffffea00095fffff] PMD ->
>> [ffff880233600000-ffff8802337fffff] on node 0
>> [ 219.371226] [ffffea0009600000-ffffea00097fffff] PMD ->
>> [ffff880233000000-ffff8802331fffff] on node 0
>> [ 219.372790] [ffffea0009800000-ffffea00099fffff] PMD ->
>> [ffff880232c00000-ffff880232dfffff] on node 0
>> [ 219.374185] [ffffea0009a00000-ffffea0009bfffff] PMD ->
>> [ffff880232200000-ffff8802323fffff] on node 0
>> [ 219.377349] [ffffea0009c00000-ffffea0009ffffff] PMD ->
>> [ffff8800b7400000-ffff8800b77fffff] on node 0
>> [ 219.378716] [ffffea000a000000-ffffea000a1fffff] PMD ->
>> [ffff8800b7000000-ffff8800b71fffff] on node 0
>> [ 219.380115] [ffffea000a200000-ffffea000a3fffff] PMD ->
>> [ffff880230c00000-ffff880230dfffff] on node 0
>> [ 219.388147] [ffffea000a400000-ffffea000abfffff] PMD ->
>> [ffff880227c00000-ffff8802283fffff] on node 0
>> [ 219.389687] [ffffea000ac00000-ffffea000adfffff] PMD ->
>> [ffff8800b7200000-ffff8800b73fffff] on node 0
>
> but “free” sstill shows the same value as before hotplug?
>
>>
>> I then shutdown the VM and power on it again and I get the changed
>> memory:
>
> well, yeah, but that doesn’t count since you’ve shut it down, so the
> next run is initialized with 10GB
>
>> $ free
>> total used free shared buff/cache
>> available
>> Mem: 10237276 167872 9919656 8480 149748 9891280
>> Swap: 839676 0 839676
>>
>> BTW: When I press ok in the gui for memory increase I get these
>> events in webadmin:
>> Dec 9, 2015 11:56:22 PM
>> VM racclient1 c71_Disk1_newtemplate disk was updated by admin at internal.
>
> hm..doesn’t sound right. Did the confirmation window show any more
> fields as changed other than memory?
>
>>
>> Dec 9, 2015 11:56:19 PM
>> VM racclient1 configuration was updated by admin at internal.
>
> that’s correct - the new base for the next run
>
>>
>> Dec 9, 2015 11:56:18 PM
>> Hotset memory: changed the amount of memory on VM racclient1 from
>> 8192 to 10240
>
> that’s the actual hotplug
>
>>
>> It doesn't seem as expected, does it?
>
> I think we’re almost there. Just need to figure out what happened in
> the guest. I would suspect a problem there
I did the same test, I obtain the same result but here is what I get
into the /var/log/messages guest (7.1) logs and not mentionned there:
unsupported configuration: maxMemory has to be specified when using
memory devices
What can't I do with this error, is it a known issue?
>
> Thanks,
> michal
>
>> Gianluca
>>
>
>
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
--
Nathanaël Blanchet
Supervision réseau
Pôle Infrastrutures Informatiques
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5
Tél. 33 (0)4 67 54 84 55
Fax 33 (0)4 67 54 84 14
blanchet at abes.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20151210/9d79aa2b/attachment-0001.html>
More information about the Users
mailing list