
Hi all, I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd? Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release? Thank you for your help

Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary On Tue, Dec 8, 2015 at 2:03 AM, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Hi all,
I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd?
It does support it, but only hot-plug not hot-unplug.
Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release?
I works with fedora and you can use it currently with this feature.
Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

--Apple-Mail-2492A218-54FA-4C99-B0AA-C7DBEB0F11DA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNCj4gT24gMDggRGVjIDIwMTUsIGF0IDExOjIwLCBZYW5pdiBEYXJ5IDx5ZGFyeUByZWRoYXQu Y29tPiB3cm90ZToNCj4gDQo+IA0KPiANCj4gWWFuaXYgRGFyeQ0KPiBUZWNobmljYWwgUHJvZHVj dCBNYW5hZ2VyDQo+IFJlZCBIYXQgSXNyYWVsIEx0ZC4NCj4gMzQgSmVydXNhbGVtIFJvYWQNCj4g QnVpbGRpbmcgQSwgNHRoIGZsb29yDQo+IFJhJ2FuYW5hLCBJc3JhZWwgNDM1MDEwOQ0KPiANCj4g VGVsIDogKzk3MiAoOSkgNzY5MjMwNg0KPiAgICAgICAgIDgyNzIzMDYNCj4gRW1haWw6IHlkYXJ5 QHJlZGhhdC5jb20NCj4gSVJDIDogeWRhcnkNCj4gDQo+PiBPbiBUdWUsIERlYyA4LCAyMDE1IGF0 IDI6MDMgQU0sIE5hdGhhbmHDq2wgQmxhbmNoZXQgPGJsYW5jaGV0QGFiZXMuZnI+IHdyb3RlOg0K Pj4gSGkgYWxsLA0KPj4gDQo+PiBJIG1heSBtaXNzIHNvbWV0aGluZyBidXQgYWNjb3JkaW5nIHRv IGh0dHA6Ly93d3cub3ZpcnQub3JnL0ZlYXR1cmVzL0hvdF9QbHVnX01lbW9yeSwgb3ZpcnQgMy42 IHdhcyBzdXBwb3NlZCB0byBzdXBwb3J0IHRoZSBob3QgcGx1ZyBtZW1vcnkgZmVhdHVyZS4gTm90 aGluZyBoYXBwZW5zIGluIHJlYWxpdHkgd2hlbiBpbmNyZWFzaW5nIG1lbW9yeSBvbiBhIHJ1bm5p bmcgdm0gd2l0aCBjZW50b3M3Lg0KPj4gSSBmb3VuZCB0aGlzIDogaHR0cDovL2xpc3RzLm92aXJ0 Lm9yZ3BpcGVybWFpbC9raW1jaGktZGV2ZWwvMjAxNS1KdW5lLzAxMDcxNC5odG1sLCBhbmQgaXQg c2VlbXMgdGhhdCBlbDcuMSBjYW4ndCBzdXBwb3J0IHRoZSBmZWF0dXJlIGJlY2F1c2Ugb2YgaXRz IGxpYnZpcnQgdmVyc2lvbiAoMS4yLjgpIHdoaWxlIHRoZSByZXF1aXJlZCBvbmUgaXMgMS4yLjE0 Lg0KPj4gSSBkaWRuJ3QgdGVzdCwgYnV0IEkgZ3Vlc3MgRjIyIHN1cHBvcnRzIGl0Lg0KPj4gSXMg dGhlcmUgYW55IGNoYW5jZSB0aGF0IGVsNy4yIHdvdWxkIHN1cHBvcnQgaXQgd2l0aCBhIGJhY2tw b3J0ZWQgbGlidmlydGQ/DQo+IA0KPiBJdCBkb2VzIHN1cHBvcnQgaXQsIGJ1dCBvbmx5IGhvdC1w bHVnIG5vdCBob3QtdW5wbHVnLg0KPiAgDQo+PiBPciB3aWxsIGEgZGVkaWNhdGVkIGxpYnZpcnQg cmhldiBwYWNrYWdlIGJlIHJlbGVhc2VkIHNvIGFzIHRoZSBkb3duc3RyZWFtIHRvIHN1cHBvcnQg aXQgKGxpa2UgcWVtdS1rdm0gZm9yIGxpdmUgc25hcHNob3Qgc29tZSB0aW1lIGFnbyk/DQo+PiBE b2N1bWVudGF0aW9uIGFuZCBsaW1pdGF0aW9uIG9mIHRoZSBsaWJ2aXJ0IHZlcnNpb24gZm9yIGhv dCBwbHVnIG1lbW9yeSBhcmUgZGlmZmljdWx0IHRvIGZpbmQgaW4gdGhlIG92aXJ0IHdpa2kgYW5k IG1vcmUgZ2VuZXJhbGx5IG9uIHRoZSB3ZWIuDQo+PiBNYXliZSB0aGUgZmVhdHVyZSBoYXMgYmVl biBwb3N0cG9uZWQgdG8gYSAzLjYueiByZWxlYXNlPw0KPiANCj4gSSB3b3JrcyB3aXRoIGZlZG9y YSBhbmQgeW91IGNhbiB1c2UgaXQgY3VycmVudGx5IHdpdGggdGhpcyBmZWF0dXJlLg0KDQpJdCB3 b3JrcyBvbiBjZW50b3MgdG9vLCBxZW11LWt2bS1ldiAyLjMgd2UgZGlzdHJpYnV0ZSBpbiBvdmly dCByZXBvDQoNCj4gIA0KPj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBVc2VycyBtYWlsaW5nIGxp c3QNCj4+IFVzZXJzQG92aXJ0Lm9yZw0KPj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFu L2xpc3RpbmZvL3VzZXJzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gVXNlcnNAb3ZpcnQub3JnDQo+ IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0K --Apple-Mail-2492A218-54FA-4C99-B0AA-C7DBEB0F11DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+T24gMDggRGVjIDIwMTUsIGF0IDExOjIwLCBZYW5pdiBE YXJ5ICZsdDs8YSBocmVmPSJtYWlsdG86eWRhcnlAcmVkaGF0LmNvbSI+eWRhcnlAcmVkaGF0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp dj48ZGl2IGRpcj0ibHRyIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGVhcj0i YWxsIj48ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+PGRpdiBkaXI9Imx0ciI+PGRp dj48ZGl2IGRpcj0ibHRyIj48cHJlIGNvbHM9IjcyIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPllhbml2IERhcnkNClRlY2huaWNhbCBQcm9kdWN0 IE1hbmFnZXINClJlZCBIYXQgSXNyYWVsIEx0ZC4NCjM0IEplcnVzYWxlbSBSb2FkDQpCdWlsZGlu ZyBBLCA0dGggZmxvb3INClJhJ2FuYW5hLCBJc3JhZWwgNDM1MDEwOQ0KDQpUZWwgOiArOTcyICg5 KSA3NjkyMzA2DQogICAgICAgIDgyNzIzMDYNCkVtYWlsOiA8YSBocmVmPSJtYWlsdG86eWRhcnlA cmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlkYXJ5QHJlZGhhdC5jb208L2E+DQpJUkMgOiB5 ZGFyeTwvc3Bhbj48L3ByZT4NCjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pg0KPGJyPjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIERlYyA4LCAyMDE1IGF0IDI6MDMgQU0sIE5h dGhhbmHDq2wgQmxhbmNoZXQgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86Ymxh bmNoZXRAYWJlcy5mciIgdGFyZ2V0PSJfYmxhbmsiPmJsYW5jaGV0QGFiZXMuZnI8L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPkhpIGFsbCw8YnI+DQo8YnI+DQpJIG1heSBtaXNzIHNvbWV0aGluZyBidXQgYWNjb3JkaW5n IHRvIDxhIGhyZWY9Imh0dHA6Ly93d3cub3ZpcnQub3JnL0ZlYXR1cmVzL0hvdF9QbHVnX01lbW9y eSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5vdmlydC5vcmcv RmVhdHVyZXMvSG90X1BsdWdfTWVtb3J5PC9hPiwgb3ZpcnQgMy42IHdhcyBzdXBwb3NlZCB0byBz dXBwb3J0IHRoZSBob3QgcGx1ZyBtZW1vcnkgZmVhdHVyZS4gTm90aGluZyBoYXBwZW5zIGluIHJl YWxpdHkgd2hlbiBpbmNyZWFzaW5nIG1lbW9yeSBvbiBhIHJ1bm5pbmcgdm0gd2l0aCBjZW50b3M3 Ljxicj4NCkkgZm91bmQgdGhpcyA6IDxhIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmdwaXBl cm1haWwva2ltY2hpLWRldmVsLzIwMTUtSnVuZS8wMTA3MTQuaHRtbCIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZ3BpcGVybWFpbC9raW1jaGkt ZGV2ZWwvMjAxNS1KdW5lLzAxMDcxNC5odG1sPC9hPiwgYW5kIGl0IHNlZW1zIHRoYXQgZWw3LjEg Y2FuJ3Qgc3VwcG9ydCB0aGUgZmVhdHVyZSBiZWNhdXNlIG9mIGl0cyBsaWJ2aXJ0IHZlcnNpb24g KDEuMi44KSB3aGlsZSB0aGUgcmVxdWlyZWQgb25lIGlzIDEuMi4xNC48YnI+DQpJIGRpZG4ndCB0 ZXN0LCBidXQgSSBndWVzcyBGMjIgc3VwcG9ydHMgaXQuPGJyPg0KSXMgdGhlcmUgYW55IGNoYW5j ZSB0aGF0IGVsNy4yIHdvdWxkIHN1cHBvcnQgaXQgd2l0aCBhIGJhY2twb3J0ZWQgbGlidmlydGQ/ PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pkl0IGRvZXMgc3VwcG9ydCBpdCwg YnV0IG9ubHkgaG90LXBsdWcgbm90IGhvdC11bnBsdWcuPGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpPciB3aWxs IGEgZGVkaWNhdGVkIGxpYnZpcnQgcmhldiBwYWNrYWdlIGJlIHJlbGVhc2VkIHNvIGFzIHRoZSBk b3duc3RyZWFtIHRvIHN1cHBvcnQgaXQgKGxpa2UgcWVtdS1rdm0gZm9yIGxpdmUgc25hcHNob3Qg c29tZSB0aW1lIGFnbyk/PGJyPg0KRG9jdW1lbnRhdGlvbiBhbmQgbGltaXRhdGlvbiBvZiB0aGUg bGlidmlydCB2ZXJzaW9uIGZvciBob3QgcGx1ZyBtZW1vcnkgYXJlIGRpZmZpY3VsdCB0byBmaW5k IGluIHRoZSBvdmlydCB3aWtpIGFuZCBtb3JlIGdlbmVyYWxseSBvbiB0aGUgd2ViLjxicj4NCk1h eWJlIHRoZSBmZWF0dXJlIGhhcyBiZWVuIHBvc3Rwb25lZCB0byBhIDMuNi56IHJlbGVhc2U/PGJy PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pkkgd29ya3Mgd2l0aCBmZWRvcmEgYW5k IHlvdSBjYW4gdXNlIGl0IGN1cnJlbnRseSB3aXRoIHRoaXMgZmVhdHVyZS48YnI+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2Pkl0IHdvcmtz IG9uIGNlbnRvcyB0b28sIHFlbXUta3ZtLWV2IDIuMyB3ZSBkaXN0cmlidXRlIGluIG92aXJ0IHJl cG88ZGl2Pjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj4mbmJz cDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRo YW5rIHlvdSBmb3IgeW91ciBoZWxwPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86VXNlcnNAb3ZpcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+VXNlcnNAb3ZpcnQub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91 c2VycyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLm92aXJ0 Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PC9kaXY+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48YnI+PHNwYW4+VXNlcnMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48 YSBocmVmPSJtYWlsdG86VXNlcnNAb3ZpcnQub3JnIj5Vc2Vyc0BvdmlydC5vcmc8L2E+PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGlu Zm8vdXNlcnMiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczwv YT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-2492A218-54FA-4C99-B0AA-C7DBEB0F11DA--

This is a multi-part message in MIME format. --------------010609060205050302070908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :
On 08 Dec 2015, at 11:20, Yaniv Dary <ydary@redhat.com=20 <mailto:ydary@redhat.com>> wrote:
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem=20 Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9)=20 7692306 8272306 Email: ydary@redhat.com <mailto:ydary@redhat.com> IRC=20 : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet <blanchet@abes=
.fr=20
<mailto:blanchet@abes.fr>> wrote:
Hi all,
I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html= , and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd?
It does support it, but only hot-plug not hot-unplug.
Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release?
I works with fedora and you can use it currently with this feature.
It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c)=20 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch
I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown device=20 type 'memory' I tried to restart vdsmd but it is the same, even on other hosts. any help will be appreciated, thank you.
Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
http://www.ovirt.org/Features/Hot_Plug_Memory</a></a>, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7.<br> I found this : <a moz-do-not-send=3D"true"
--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------010609060205050302070908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> <br> <div class=3D"moz-cite-prefix">Le 08/12/2015 11:43, Michal Skrivanek = a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Du= tf-8"> <div><br> </div> <div><br> On 08 Dec 2015, at 11:20, Yaniv Dary <<a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com"><a cl= ass=3D"moz-txt-link-abbreviated" href=3D"mailto:ydary@redhat.com">ydary@r= edhat.com</a></a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div> <div dir=3D"ltr"><br> <div class=3D"gmail_extra"><br clear=3D"all"> <div> <div class=3D"gmail_signature"> <div dir=3D"ltr"> <div> <div dir=3D"ltr"> <pre cols=3D"72"><span style=3D"font-family:arial= ,helvetica,sans-serif">Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" targe= t=3D"_blank">ydary@redhat.com</a> IRC : ydary</span></pre> </div> </div> </div> </div> </div> <br> <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet <span dir=3D"ltr"><<a moz-do-not-send=3D"true" href=3D"mailto:blanchet@abes.fr" target=3D"_blank"><a= class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">blan= chet@abes.fr</a></a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br> <br> I may miss something but according to <a moz-do-not-send=3D"true" href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory= " rel=3D"noreferrer" target=3D"_blank"><a class=3D"moz-= txt-link-freetext" href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory"= href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.htm= l" rel=3D"noreferrer" target=3D"_blank">http://lists.ovi= rt.orgpipermail/kimchi-devel/2015-June/010714.html</a>, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14.<br> I didn't test, but I guess F22 supports it.<br> Is there any chance that el7.2 would support it with a backported libvirtd?<br> </blockquote> <div><br> </div> <div>It does support it, but only hot-plug not hot-unplug.<br> </div> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)?<br> Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web.<br> Maybe the feature has been postponed to a 3.6.z release?<br> </blockquote> <div><br> </div> <div>I works with fedora and you can use it currently with this feature.<br> </div> </div> </div> </div> </div> </blockquote> <div><br> </div> It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo</blockquote> Hello, no qemu-kvm-ev 2.3 is not enough:<br> [root@fuji ~]# qemu-img --version<br> qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard<br> and<br> vdsm-4.17.10.1-0.el7.centos.noarch<br> <br> I get this error message each time I try to hot add memory :<br> Dec=C2=A0 9 11:18:00 fuji journal: unsupported configuration: unknown device type 'memory'<br> <br> I tried to restart vdsmd but it is the same, even on other hosts.<br> <br> any help will be appreciated, thank you.<br> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"> <div><br> <blockquote type=3D"cite"> <div> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you for your help<br> _______________________________________________<br> Users mailing list<br> <a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org" target=3D"_blank">U= sers@ovirt.org</a><br> <a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/mailman/listinfo/use= rs" rel=3D"noreferrer" target=3D"_blank">http://lists.o= virt.org/mailman/listinfo/users</a><br> </blockquote> </div> <br> </div> </div> </div> </blockquote> <blockquote type=3D"cite"> <div><span>_______________________________________________</spa= n><br> <span>Users mailing list</span><br> <span><a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org">Users@ovirt.org</a></span=
<br> <span><a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/mailman/listinfo/users">ht= tp://lists.ovirt.org/mailman/listinfo/users</a></span><br> </div> </blockquote> </div> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet
Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------010609060205050302070908--

On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr> = wrote: =20 =20 =20 Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :
=20 =20 On 08 Dec 2015, at 11:20, Yaniv Dary < = <mailto:ydary@redhat.com>ydary@redhat.com <mailto:ydary@redhat.com>> = wrote: =20
=20 =20 Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 =20 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com <mailto:ydary@redhat.com> IRC : ydary =20 On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet < = <mailto:blanchet@abes.fr>blanchet@abes.fr <mailto:blanchet@abes.fr>> = wrote: Hi all, =20 I may miss something but according to = <http://www.ovirt.org/Features/Hot_Plug_Memory>http://www.ovirt.org/Featur= es/Hot_Plug_Memory <http://www.ovirt.org/Features/Hot_Plug_Memory>, = ovirt 3.6 was supposed to support the hot plug memory feature. Nothing = happens in reality when increasing memory on a running vm with centos7. I found this : = http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html = <http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html>, = and it seems that el7.1 can't support the feature because of its libvirt = version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported =
--Apple-Mail=_8A47B8CA-BC31-4809-A2A5-98B564DFE94F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 libvirtd?
=20 It does support it, but only hot-plug not hot-unplug. =20 Or will a dedicated libvirt rhev package be released so as the = downstream to support it (like qemu-kvm for live snapshot some time = ago)? Documentation and limitation of the libvirt version for hot plug = memory are difficult to find in the ovirt wiki and more generally on the = web. Maybe the feature has been postponed to a 3.6.z release? =20 I works with fedora and you can use it currently with this feature. =20 It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) = 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch =20 I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown = device type =E2=80=98memory'
was the VM started in a 3.6 cluster?=20 Or how/when did you create it? Thanks, michal
=20 I tried to restart vdsmd but it is the same, even on other hosts. =20 any help will be appreciated, thank you.
=20
=20 Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 --=20 Nathana=C3=ABl Blanchet =20 Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>=20
--Apple-Mail=_8A47B8CA-BC31-4809-A2A5-98B564DFE94F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet <<a = href=3D"mailto:blanchet@abes.fr" class=3D"">blanchet@abes.fr</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""> =20 <meta content=3D"text/html; charset=3Dutf-8" = http-equiv=3D"Content-Type" class=3D""> =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 08/12/2015 11:43, Michal Skrivanek = a =C3=A9crit :<br class=3D""> </div> <blockquote = cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"= class=3D""> <meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8" class=3D""> <div class=3D""><br class=3D""> </div> <div class=3D""><br class=3D""> On 08 Dec 2015, at 11:20, Yaniv Dary <<a = moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" = class=3D""></a><a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:ydary@redhat.com">ydary@redhat.com</a>> wrote:<br class=3D""> <br class=3D""> </div> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""><br class=3D""> <div class=3D"gmail_extra"><br clear=3D"all" class=3D""> <div class=3D""> <div class=3D"gmail_signature"> <div dir=3D"ltr" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <pre cols=3D"72" class=3D""><span = style=3D"font-family:arial,helvetica,sans-serif" class=3D"">Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" = target=3D"_blank" class=3D"">ydary@redhat.com</a> IRC : ydary</span></pre> </div> </div> </div> </div> </div> <br class=3D""> <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet <span dir=3D"ltr" = class=3D""><<a moz-do-not-send=3D"true" = href=3D"mailto:blanchet@abes.fr" target=3D"_blank" class=3D""></a><a = class=3D"moz-txt-link-abbreviated" = href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a>></span> wrote:<br class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class=3D""> <br class=3D""> I may miss something but according to <a = moz-do-not-send=3D"true" = href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory" rel=3D"noreferrer" = target=3D"_blank" class=3D""></a><a class=3D"moz-txt-link-freetext" = href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory">http://www.ovirt.or= g/Features/Hot_Plug_Memory</a>, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7.<br class=3D""> I found this : <a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html= " rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.h= tml</a>, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14.<br class=3D""> I didn't test, but I guess F22 supports it.<br = class=3D""> Is there any chance that el7.2 would support it with a backported libvirtd?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">It does support it, but only hot-plug = not hot-unplug.<br class=3D""> </div> <div class=3D""> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)?<br class=3D""> Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web.<br class=3D""> Maybe the feature has been postponed to a 3.6.z release?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">I works with fedora and you can use it = currently with this feature.<br class=3D""> </div> </div> </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo</blockquote> Hello, no qemu-kvm-ev 2.3 is not enough:<br class=3D""> [root@fuji ~]# qemu-img --version<br class=3D""> qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard<br class=3D""> and<br class=3D""> vdsm-4.17.10.1-0.el7.centos.noarch<br class=3D""> <br class=3D""> I get this error message each time I try to hot add memory :<br = class=3D""> Dec 9 11:18:00 fuji journal: unsupported configuration: = unknown device type =E2=80=98memory'<br = class=3D""></div></div></blockquote><div><br class=3D""></div>was the VM = started in a 3.6 cluster? </div><div>Or how/when did you create = it?</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> I tried to restart vdsmd but it is the same, even on other hosts.<br = class=3D""> <br class=3D""> any help will be appreciated, thank you.<br class=3D""> <blockquote = cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"= class=3D""> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div class=3D""> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you for your help<br class=3D""> _______________________________________________<br = class=3D""> Users mailing list<br class=3D""> <a moz-do-not-send=3D"true" = href=3D"mailto:Users@ovirt.org" target=3D"_blank" = class=3D"">Users@ovirt.org</a><br class=3D""> <a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.org/mailman/listinfo/users" rel=3D"noreferrer" = target=3D"_blank" = class=3D"">http://lists.ovirt.org/mailman/listinfo/users</a><br = class=3D""> </blockquote> </div> <br class=3D""> </div> </div> </div> </blockquote> <blockquote type=3D"cite" class=3D""> <div class=3D""><span = class=3D"">_______________________________________________</span><br = class=3D""> <span class=3D"">Users mailing list</span><br class=3D""> <span class=3D""><a moz-do-not-send=3D"true" = href=3D"mailto:Users@ovirt.org" class=3D"">Users@ovirt.org</a></span><br = class=3D""> <span class=3D""><a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.org/mailman/listinfo/users" = class=3D"">http://lists.ovirt.org/mailman/listinfo/users</a></span><br = class=3D""> </div> </blockquote> </div> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_8A47B8CA-BC31-4809-A2A5-98B564DFE94F--

This is a multi-part message in MIME format. --------------080201090102080009050406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 09/12/2015 17:12, Michal Skrivanek a =C3=A9crit :
On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr=20 <mailto:blanchet@abes.fr>> wrote:
Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :
On 08 Dec 2015, at 11:20, Yaniv Dary <ydary@redhat.com> wrote:
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34=20 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel :=20 +972 (9) 7692306 8272306 Email: ydary@redhat.com=20 <mailto:ydary@redhat.com> IRC : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet=20 <blanchet@abes.fr> wrote:
Hi all,
I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.ht=
and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd?
It does support it, but only hot-plug not hot-unplug.
Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release?
I works with fedora and you can use it currently with this feature.
It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c)=20 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch
I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown=20 device type =E2=80=98memory'
was the VM started in a 3.6 cluster? sure, on a full 3.6 cluster. I stopped/restarted them. I restarted vdsmd=20 and libvirtd Or how/when did you create it?
ml, those vms have been created before uprading to 3.6, some of them from a=20 blank template, other one based on a el7 template.
Thanks, michal
I tried to restart vdsmd but it is the same, even on other hosts.
any help will be appreciated, thank you.
Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
--=20 Nathana=C3=ABl Blanchet
Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr =20
--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------080201090102080009050406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> <br> <div class=3D"moz-cite-prefix">Le 09/12/2015 17:12, Michal Skrivanek = a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du= tf-8"> <br class=3D""> <div> <blockquote type=3D"cite" class=3D""> <div class=3D"">On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanch= et <<a moz-do-not-send=3D"true" href=3D"mailto:blanchet@abes.= fr" class=3D"">blanchet@abes.fr</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type" class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit=C2=A0:<br class=3D""> </div> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.c= om" type=3D"cite" class=3D""> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8" class=3D""> <div class=3D""><br class=3D""> </div> <div class=3D""><br class=3D""> On 08 Dec 2015, at 11:20, Yaniv Dary <<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"mailto:ydary@redhat.com"><a class=3D"moz-txt-= link-abbreviated" href=3D"mailto:ydary@redhat.com">ydary@redhat.com</a></= a>> wrote:<br class=3D""> <br class=3D""> </div> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""><br class=3D""> <div class=3D"gmail_extra"><br class=3D"" clear=3D"= all"> <div class=3D""> <div class=3D"gmail_signature"> <div dir=3D"ltr" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <pre cols=3D"72" class=3D""><span style= =3D"font-family:arial,helvetica,sans-serif" class=3D"">Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" targe= t=3D"_blank" class=3D"">ydary@redhat.com</a> IRC : ydary</span></pre> </div> </div> </div> </div> </div> <br class=3D""> <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet <span dir=3D"l= tr" class=3D""><<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">blanchet@a= bes.fr</a>></span> wrote:<br class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class=3D""> <br class=3D""> I may miss something but according to <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"http://www.ovirt.org/Features/Hot_P= lug_Memory"><a class=3D"moz-txt-link-freetext" href=3D"http://www.ovirt.o= rg/Features/Hot_Plug_Memory">http://www.ovirt.org/Features/Hot_Plug_Memor= y</a></a>, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7.<br class=3D""> I found this : <a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.htm= l" rel=3D"noreferrer" target=3D"_blank" class=3D= "">http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html</a>= , and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14.<br class=3D""> I didn't test, but I guess F22 supports it.<b= r class=3D""> Is there any chance that el7.2 would support it with a backported libvirtd?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">It does support it, but only hot-plug not hot-unplug.<br class=3D""> </div> <div class=3D"">=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)?<br class=3D""> Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web.<br class=3D""> Maybe the feature has been postponed to a 3.6.z release?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">I works with fedora and you can use it currently with this feature.<br class=3D""> </div> </div> </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo</blockquote> Hello, no qemu-kvm-ev 2.3 is not enough:<br class=3D""> [root@fuji ~]# qemu-img --version<br class=3D""> qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard<br class=3D""> and<br class=3D""> vdsm-4.17.10.1-0.el7.centos.noarch<br class=3D""> <br class=3D""> I get this error message each time I try to hot add memory :<br class=3D""> Dec=C2=A0 9 11:18:00 fuji journal: unsupported configuratio= n: unknown device type =E2=80=98memory'<br class=3D""> </div> </div> </blockquote> <div><br class=3D""> </div> was the VM started in a 3.6 cluster? <br> </div> </blockquote> sure, on a full 3.6 cluster. I stopped/restarted them. I restarted vdsmd and libvirtd<br> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"> <div>Or how/when did you create it?</div> </blockquote> those vms have been created before uprading to 3.6, some of them from a blank template, other one based on a el7 template.<br> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"> <div><br class=3D""> </div> <div>Thanks,</div> <div>michal</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> I tried to restart vdsmd but it is the same, even on other hosts.<br class=3D""> <br class=3D""> any help will be appreciated, thank you.<br class=3D""> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.c= om" type=3D"cite" class=3D""> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div class=3D"">=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you for your help<br class=3D""> _______________________________________________<br class=3D""> Users mailing list<br class=3D""> <a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org" target=3D"_blank" class=3D"">Users@ovirt.= org</a><br class=3D""> <a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/mailman/li= stinfo/users" rel=3D"noreferrer" target=3D"_blank" class=3D"">http://lists.ovirt.org/mailman= /listinfo/users</a><br class=3D""> </blockquote> </div> <br class=3D""> </div> </div> </div> </blockquote> <blockquote type=3D"cite" class=3D""> <div class=3D""><span class=3D"">____________________= ___________________________</span><br class=3D""> <span class=3D"">Users mailing list</span><br class=3D""> <span class=3D""><a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org" class=3D"">User= s@ovirt.org</a></span><br class=3D""> <span class=3D""><a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/mailman/listinfo= /users" class=3D"">http://lists.ovirt.org/mailman/listi= nfo/users</a></span><br class=3D""> </div> </blockquote> </div> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"ma= ilto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div> </blockquote> </div> <br class=3D""> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------080201090102080009050406--

On 09 Dec 2015, at 17:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr> = wrote: =20 =20 =20 Le 09/12/2015 17:12, Michal Skrivanek a =C3=A9crit :
=20
On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr = <mailto:blanchet@abes.fr>> wrote: =20 =20 =20 Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :
=20 =20 On 08 Dec 2015, at 11:20, Yaniv Dary < = <mailto:ydary@redhat.com>ydary@redhat.com <mailto:ydary@redhat.com>> = wrote: =20
=20 =20 Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 =20 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com <mailto:ydary@redhat.com> IRC : ydary =20 On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet = <blanchet@abes.fr <mailto:blanchet@abes.fr>> wrote: Hi all, =20 I may miss something but according to = <http://www.ovirt.org/Features/Hot_Plug_Memory>http://www.ovirt.org/Featur= es/Hot_Plug_Memory <http://www.ovirt.org/Features/Hot_Plug_Memory>, = ovirt 3.6 was supposed to support the hot plug memory feature. Nothing = happens in reality when increasing memory on a running vm with centos7. I found this : = http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html = <http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html>, = and it seems that el7.1 can't support the feature because of its libvirt = version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported =
--Apple-Mail=_9E193F6D-8986-4D9D-9C11-5DD9F6C4E0C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 libvirtd?
=20 It does support it, but only hot-plug not hot-unplug. =20 Or will a dedicated libvirt rhev package be released so as the = downstream to support it (like qemu-kvm for live snapshot some time = ago)? Documentation and limitation of the libvirt version for hot plug = memory are difficult to find in the ovirt wiki and more generally on the = web. Maybe the feature has been postponed to a 3.6.z release? =20 I works with fedora and you can use it currently with this = feature. =20 It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) = 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch =20 I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown = device type =E2=80=98memory' =20 was the VM started in a 3.6 cluster?=20 sure, on a full 3.6 cluster. I stopped/restarted them. I restarted = vdsmd and libvirtd
ok..and just for the sake of completeness - what is libvirt version = exactly? If you=E2=80=99re running <1.2.14 then your initial comment = make a lot of sense=E2=80=A6. Yes, el7.2 has the right one (1.2.17) but even on 7.1 it should support = it and if it doesn=E2=80=99t it=E2=80=99s our problem we should fix in = ovirt (similarly as we solve qemu by shipping it ourselves)
Or how/when did you create it? those vms have been created before uprading to 3.6, some of them from = a blank template, other one based on a el7 template. =20 Thanks, michal =20
=20 I tried to restart vdsmd but it is the same, even on other hosts. =20 any help will be appreciated, thank you.
=20
=20 Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> =20 --=20 Nathana=C3=ABl Blanchet =20 Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>=20 =20 =20 --=20 Nathana=C3=ABl Blanchet =20 Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr <mailto:blanchet@abes.fr>=20
--Apple-Mail=_9E193F6D-8986-4D9D-9C11-5DD9F6C4E0C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 09 Dec 2015, at 17:54, Nathana=C3=ABl Blanchet <<a = href=3D"mailto:blanchet@abes.fr" class=3D"">blanchet@abes.fr</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""> =20 <meta content=3D"text/html; charset=3Dutf-8" = http-equiv=3D"Content-Type" class=3D""> =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 09/12/2015 17:12, Michal Skrivanek = a =C3=A9crit :<br class=3D""> </div> <blockquote = cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"= class=3D""> <meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8" class=3D""> <br class=3D""> <div class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D"">On 09 Dec 2015, at 14:54, Nathana=C3=ABl = Blanchet <<a moz-do-not-send=3D"true" = href=3D"mailto:blanchet@abes.fr" class=3D"">blanchet@abes.fr</a>> = wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <meta content=3D"text/html; charset=3Dutf-8" = http-equiv=3D"Content-Type" class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br = class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :<br class=3D""> </div> <blockquote = cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"= class=3D""> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8" class=3D""> <div class=3D""><br class=3D""> </div> <div class=3D""><br class=3D""> On 08 Dec 2015, at 11:20, Yaniv Dary <<a = moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" = href=3D"mailto:ydary@redhat.com"></a><a class=3D"moz-txt-link-abbreviated"= href=3D"mailto:ydary@redhat.com">ydary@redhat.com</a>> wrote:<br class=3D""> <br class=3D""> </div> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""><br class=3D""> <div class=3D"gmail_extra"><br class=3D"" = clear=3D"all"> <div class=3D""> <div class=3D"gmail_signature"> <div dir=3D"ltr" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <pre cols=3D"72" class=3D""><span = style=3D"font-family:arial,helvetica,sans-serif" class=3D"">Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" = target=3D"_blank" class=3D"">ydary@redhat.com</a> IRC : ydary</span></pre> </div> </div> </div> </div> </div> <br class=3D""> <div class=3D"gmail_quote">On Tue, Dec 8, 2015 = at 2:03 AM, Nathana=C3=ABl Blanchet <span = dir=3D"ltr" class=3D""><<a moz-do-not-send=3D"true" = class=3D"moz-txt-link-abbreviated" = href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a>></span> wrote:<br class=3D""> <blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br = class=3D""> <br class=3D""> I may miss something but according to <a = moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" = href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory"></a><a = class=3D"moz-txt-link-freetext" = href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory">http://www.ovirt.or= g/Features/Hot_Plug_Memory</a>, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7.<br class=3D""> I found this : <a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html= " rel=3D"noreferrer" target=3D"_blank" = class=3D"">http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.h= tml</a>, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14.<br = class=3D""> I didn't test, but I guess F22 supports = it.<br class=3D""> Is there any chance that el7.2 would support it with a backported libvirtd?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">It does support it, but only hot-plug not hot-unplug.<br class=3D""> </div> <div class=3D""> </div> <blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time = ago)?<br class=3D""> Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web.<br class=3D""> Maybe the feature has been postponed to a 3.6.z release?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">I works with fedora and you = can use it currently with this feature.<br = class=3D""> </div> </div> </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo</blockquote> Hello, no qemu-kvm-ev 2.3 is not enough:<br class=3D""> [root@fuji ~]# qemu-img --version<br class=3D""> qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard<br class=3D""> and<br class=3D""> vdsm-4.17.10.1-0.el7.centos.noarch<br class=3D""> <br class=3D""> I get this error message each time I try to hot add memory :<br class=3D""> Dec 9 11:18:00 fuji journal: unsupported = configuration: unknown device type =E2=80=98memory'<br class=3D""> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> was the VM started in a 3.6 cluster? <br class=3D""> </div> </blockquote> sure, on a full 3.6 cluster. I stopped/restarted them. I restarted vdsmd and libvirtd<br class=3D""></div></div></blockquote><div><br = class=3D""></div>ok..and just for the sake of completeness - what is = libvirt version exactly? If you=E2=80=99re running <1.2.14 then your = initial comment make a lot of sense=E2=80=A6.</div><div>Yes, el7.2 has = the right one (1.2.17) but even on 7.1 it should support it and if it = doesn=E2=80=99t it=E2=80=99s our problem we should fix in ovirt = (similarly as we solve qemu by shipping it ourselves)</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <blockquote = cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"= class=3D""> <div class=3D"">Or how/when did you create it?</div> </blockquote> those vms have been created before uprading to 3.6, some of them from a blank template, other one based on a el7 template.<br = class=3D""> <blockquote = cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.com" type=3D"cite"= class=3D""> <div class=3D""><br class=3D""> </div> <div class=3D"">Thanks,</div> <div class=3D"">michal</div> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br = class=3D""> I tried to restart vdsmd but it is the same, even on other hosts.<br class=3D""> <br class=3D""> any help will be appreciated, thank you.<br class=3D""> <blockquote = cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201C@redhat.com" type=3D"cite"= class=3D""> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div class=3D""> </div> <blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you for your help<br class=3D""> _______________________________________________<br class=3D""> Users mailing list<br class=3D""> <a moz-do-not-send=3D"true" = href=3D"mailto:Users@ovirt.org" target=3D"_blank" = class=3D"">Users@ovirt.org</a><br class=3D""> <a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.org/mailman/listinfo/users" rel=3D"noreferrer" = target=3D"_blank" = class=3D"">http://lists.ovirt.org/mailman/listinfo/users</a><br = class=3D""> </blockquote> </div> <br class=3D""> </div> </div> </div> </blockquote> <blockquote type=3D"cite" class=3D""> <div class=3D""><span = class=3D"">_______________________________________________</span><br = class=3D""> <span class=3D"">Users mailing list</span><br = class=3D""> <span class=3D""><a moz-do-not-send=3D"true" = href=3D"mailto:Users@ovirt.org" class=3D"">Users@ovirt.org</a></span><br = class=3D""> <span class=3D""><a moz-do-not-send=3D"true" = href=3D"http://lists.ovirt.org/mailman/listinfo/users" = class=3D"">http://lists.ovirt.org/mailman/listinfo/users</a></span><br = class=3D""> </div> </blockquote> </div> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" = href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div> </blockquote> </div> <br class=3D""> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" = href=3D"mailto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_9E193F6D-8986-4D9D-9C11-5DD9F6C4E0C5--

This is a multi-part message in MIME format. --------------000509010800090403090309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 09/12/2015 18:00, Michal Skrivanek a =C3=A9crit :
On 09 Dec 2015, at 17:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr=20 <mailto:blanchet@abes.fr>> wrote:
Le 09/12/2015 17:12, Michal Skrivanek a =C3=A9crit :
On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet <blanchet@abes.fr=20 <mailto:blanchet@abes.fr>> wrote:
Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit :
On 08 Dec 2015, at 11:20, Yaniv Dary <ydary@redhat.com> wrote:
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34=20 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel=20 : +972 (9) 7692306 8272306 Email: ydary@redhat.com=20 <mailto:ydary@redhat.com> IRC : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet=20 <blanchet@abes.fr> wrote:
Hi all,
I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.=
and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd?
It does support it, but only hot-plug not hot-unplug.
Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release?
I works with fedora and you can use it currently with this feature=
.
It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c)=20 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch
I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown=20 device type =E2=80=98memory'
was the VM started in a 3.6 cluster? sure, on a full 3.6 cluster. I stopped/restarted them. I restarted=20 vdsmd and libvirtd
ok..and just for the sake of completeness - what is libvirt version=20 exactly? If you=E2=80=99re running <1.2.14 then your initial comment ma= ke a=20 lot of sense=E2=80=A6. Yes, el7.2 has the right one (1.2.17) but even on 7.1 it should=20 support it and if it doesn=E2=80=99t it=E2=80=99s our problem we should= fix in ovirt=20 (similarly as we solve qemu by shipping it ourselves)
html, libvirt-daemon-1.2.8-16.el7_1.5.x86_64 I'm really surprised that such a waited feature has not been yet tested=20 by the community users with el7, so that nobody has reported the issue ye= t.
Or how/when did you create it? those vms have been created before uprading to 3.6, some of them from=20 a blank template, other one based on a el7 template.
Thanks, michal
I tried to restart vdsmd but it is the same, even on other hosts.
any help will be appreciated, thank you.
Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users
--=20 Nathana=C3=ABl Blanchet
Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr =20
--=20 Nathana=C3=ABl Blanchet
Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr =20
<<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated= " href=3D"mailto:blanchet@abes.fr">= <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a></a>></span> wrote:<br class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class=3D""> <br class=3D""> I may miss something but according to <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"http://www.ovirt.org/Feat= ures/Hot_Plug_Memory">http://www.ovirt.org/Features/Hot_Plug_Memory</a>, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7.<br class=3D""> I found this : <a moz-do-not-send=3D"true"
<br class=3D""> <span class=3D""><a moz-do-not-send=3D"tr= ue" href=3D"mailto:Users@ovirt.org" class=3D"">Users@ovirt.org</a></span>= <br class=3D""> <span class=3D""><a moz-do-not-send=3D"tr= ue"
--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------000509010800090403090309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty= pe"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> <br> <div class=3D"moz-cite-prefix">Le 09/12/2015 18:00, Michal Skrivanek = a =C3=A9crit=C2=A0:<br> </div> <blockquote cite=3D"mid:C2AA0E08-6714-4C28-874D-B3C9F9310288@redhat.com" type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Du= tf-8"> <br class=3D""> <div> <blockquote type=3D"cite" class=3D""> <div class=3D"">On 09 Dec 2015, at 17:54, Nathana=C3=ABl Blanch= et <<a moz-do-not-send=3D"true" href=3D"mailto:blanchet@abes.= fr" class=3D"">blanchet@abes.fr</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type" class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 09/12/2015 17:12, Michal Skrivanek a =C3=A9crit=C2=A0:<br class=3D""> </div> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.c= om" type=3D"cite" class=3D""> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" class=3D""> <br class=3D""> <div class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D"">On 09 Dec 2015, at 14:54, Nathana=C3=AB= l Blanchet <<a moz-do-not-send=3D"true" href=3D"mailto:blanchet@abes.fr" class=3D"">blanc= het@abes.fr</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type" class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"= "> <br class=3D""> <br class=3D""> <div class=3D"moz-cite-prefix">Le 08/12/2015 11:43, Michal Skrivanek a =C3=A9crit=C2=A0:<br = class=3D""> </div> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201= C@redhat.com" type=3D"cite" class=3D""> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8" class=3D= ""> <div class=3D""><br class=3D""> </div> <div class=3D""><br class=3D""> On 08 Dec 2015, at 11:20, Yaniv Dary <<a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"mailto:ydary@redhat.com"><a class=3D= "moz-txt-link-abbreviated" href=3D"mailto:ydary@redhat.com">ydary@redhat.= com</a></a>> wrote:<br class=3D""> <br class=3D""> </div> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""><br class=3D""> <div class=3D"gmail_extra"><br class=3D"" clear=3D"all"> <div class=3D""> <div class=3D"gmail_signature"> <div dir=3D"ltr" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <pre cols=3D"72" class=3D""><= span style=3D"font-family:arial,helvetica,sans-serif" class=3D"">Yaniv Da= ry Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a moz-do-not-send=3D"true" href=3D"mailto:ydary@redhat.com" targe= t=3D"_blank" class=3D"">ydary@redhat.com</a> IRC : ydary</span></pre> </div> </div> </div> </div> </div> <br class=3D""> <div class=3D"gmail_quote">On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet <span dir=3D"ltr" class=3D""= href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.htm= l" rel=3D"noreferrer" target=3D"_bla= nk" class=3D""><a class=3D"moz-txt-li= nk-freetext" href=3D"http://lists.ovirt.orgpipermail/kimchi-devel/2015-Ju= ne/010714.html">http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/01= 0714.html</a></a>, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14.<br class=3D""> I didn't test, but I guess F22 supports it.<br class=3D""> Is there any chance that el7.2 would support it with a backported libvirtd?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">It does support it, but only hot-plug not hot-unplug.<b= r class=3D""> </div> <div class=3D"">=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)?<br class=3D""> Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web.<br class=3D""> Maybe the feature has been postponed to a 3.6.z release?<br class=3D""> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">I works with fedora and you can use it currently with this feature.<br class=3D""> </div> </div> </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo</blockquote> Hello, no qemu-kvm-ev 2.3 is not enough:<br class=3D""> [root@fuji ~]# qemu-img --version<br class=3D""> qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard<br class=3D""> and<br class=3D""> vdsm-4.17.10.1-0.el7.centos.noarch<br class=3D""> <br class=3D""> I get this error message each time I try to hot add memory :<br class=3D""> Dec=C2=A0 9 11:18:00 fuji journal: unsupported configuration: unknown device type =E2=80=98memor= y'<br class=3D""> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> was the VM started in a 3.6 cluster? <br class=3D""> </div> </blockquote> sure, on a full 3.6 cluster. I stopped/restarted them. I restarted vdsmd and libvirtd<br class=3D""> </div> </div> </blockquote> <div><br class=3D""> </div> ok..and just for the sake of completeness - what is libvirt version exactly? If you=E2=80=99re running <1.2.14 then your i= nitial comment make a lot of sense=E2=80=A6.</div> <div>Yes, el7.2 has the right one (1.2.17) but even on 7.1 it should support it and if it doesn=E2=80=99t it=E2=80=99s our prob= lem we should fix in ovirt (similarly as we solve qemu by shipping it ourselves)<br> </div> </blockquote> libvirt-daemon-1.2.8-16.el7_1.5.x86_64<br> I'm really surprised that such a waited feature has not been yet tested by the community users with el7, so that nobody has reported the issue yet.<br> <blockquote cite=3D"mid:C2AA0E08-6714-4C28-874D-B3C9F9310288@redhat.com" type=3D"cite"> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.c= om" type=3D"cite" class=3D""> <div class=3D"">Or how/when did you create it?</div> </blockquote> those vms have been created before uprading to 3.6, some of them from a blank template, other one based on a el7 template.<br class=3D""> <blockquote cite=3D"mid:0088FD32-A067-425B-B4D2-02D3B802B4FE@redhat.c= om" type=3D"cite" class=3D""> <div class=3D""><br class=3D""> </div> <div class=3D"">Thanks,</div> <div class=3D"">michal</div> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"= "> <br class=3D""> I tried to restart vdsmd but it is the same, even on other hosts.<br class=3D""> <br class=3D""> any help will be appreciated, thank you.<br class=3D""> <blockquote cite=3D"mid:59A957BB-B21F-4666-A599-2ED333C8201= C@redhat.com" type=3D"cite" class=3D""> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div class=3D"">=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thank you for your help<br class=3D""> _______________________________________________<br class=3D""> Users mailing list<br class=3D""> <a moz-do-not-send=3D"true" href=3D"mailto:Users@ovirt.org" target=3D"_blank" class=3D"">Us= ers@ovirt.org</a><br class=3D""> <a moz-do-not-send=3D"true" href=3D"http://lists.ovirt.org/= mailman/listinfo/users" rel=3D"noreferrer" target=3D"_blank" class=3D"">ht= tp://lists.ovirt.org/mailman/listinfo/users</a><br class=3D""> </blockquote> </div> <br class=3D""> </div> </div> </div> </blockquote> <blockquote type=3D"cite" class=3D""> <div class=3D""><span class=3D"">__________= _____________________________________</span><br class=3D""> <span class=3D"">Users mailing list</span= href=3D"http://lists.ovirt.org/mailman/listinfo/users" class=3D"">http://= lists.ovirt.org/mailman/listinfo/users</a></span><br class=3D""> </div> </blockquote> </div> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"ma= ilto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div> </blockquote> </div> <br class=3D""> </blockquote> <br class=3D""> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a moz-do-not-send=3D"true" class=3D"moz-txt-link-abbreviated" href=3D"ma= ilto:blanchet@abes.fr">blanchet@abes.fr</a> </pre> </div> </div> </blockquote> </div> <br class=3D""> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------000509010800090403090309--

--Apple-Mail-B756CF2D-7AA7-41EC-8110-C54B216C8099 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQoNCj4gT24gMDkgRGVjIDIwMTUsIGF0IDE4OjA3LCBOYXRoYW5hw6tsIEJsYW5jaGV0IDxibGFu Y2hldEBhYmVzLmZyPiB3cm90ZToNCj4gDQo+IA0KPiANCj4gTGUgMDkvMTIvMjAxNSAxODowMCwg TWljaGFsIFNrcml2YW5layBhIMOpY3JpdCA6DQo+PiANCj4+PiBPbiAwOSBEZWMgMjAxNSwgYXQg MTc6NTQsIE5hdGhhbmHDq2wgQmxhbmNoZXQgPGJsYW5jaGV0QGFiZXMuZnI+IHdyb3RlOg0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IExlIDA5LzEyLzIwMTUgMTc6MTIsIE1pY2hhbCBTa3JpdmFuZWsg YSDDqWNyaXQgOg0KPj4+PiANCj4+Pj4+IE9uIDA5IERlYyAyMDE1LCBhdCAxNDo1NCwgTmF0aGFu YcOrbCBCbGFuY2hldCA8YmxhbmNoZXRAYWJlcy5mcj4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IA0K Pj4+Pj4gDQo+Pj4+PiBMZSAwOC8xMi8yMDE1IDExOjQzLCBNaWNoYWwgU2tyaXZhbmVrIGEgw6lj cml0IDoNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiAwOCBEZWMgMjAxNSwgYXQgMTE6MjAs IFlhbml2IERhcnkgPHlkYXJ5QHJlZGhhdC5jb20+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gDQo+Pj4+Pj4+IFlhbml2IERhcnkNCj4+Pj4+Pj4gVGVjaG5pY2FsIFByb2R1Y3Qg TWFuYWdlcg0KPj4+Pj4+PiBSZWQgSGF0IElzcmFlbCBMdGQuDQo+Pj4+Pj4+IDM0IEplcnVzYWxl bSBSb2FkDQo+Pj4+Pj4+IEJ1aWxkaW5nIEEsIDR0aCBmbG9vcg0KPj4+Pj4+PiBSYSdhbmFuYSwg SXNyYWVsIDQzNTAxMDkNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRlbCA6ICs5NzIgKDkpIDc2OTIzMDYN Cj4+Pj4+Pj4gICAgICAgICA4MjcyMzA2DQo+Pj4+Pj4+IEVtYWlsOiB5ZGFyeUByZWRoYXQuY29t DQo+Pj4+Pj4+IElSQyA6IHlkYXJ5DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gVHVlLCBEZWMgOCwg MjAxNSBhdCAyOjAzIEFNLCBOYXRoYW5hw6tsIEJsYW5jaGV0IDxibGFuY2hldEBhYmVzLmZyPiB3 cm90ZToNCj4+Pj4+Pj4+IEhpIGFsbCwNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSSBtYXkgbWlzcyBz b21ldGhpbmcgYnV0IGFjY29yZGluZyB0byBodHRwOi8vd3d3Lm92aXJ0Lm9yZy9GZWF0dXJlcy9I b3RfUGx1Z19NZW1vcnksIG92aXJ0IDMuNiB3YXMgc3VwcG9zZWQgdG8gc3VwcG9ydCB0aGUgaG90 IHBsdWcgbWVtb3J5IGZlYXR1cmUuIE5vdGhpbmcgaGFwcGVucyBpbiByZWFsaXR5IHdoZW4gaW5j cmVhc2luZyBtZW1vcnkgb24gYSBydW5uaW5nIHZtIHdpdGggY2VudG9zNy4NCj4+Pj4+Pj4+IEkg Zm91bmQgdGhpcyA6IGh0dHA6Ly9saXN0cy5vdmlydC5vcmdwaXBlcm1haWwva2ltY2hpLWRldmVs LzIwMTUtSnVuZS8wMTA3MTQuaHRtbCwgYW5kIGl0IHNlZW1zIHRoYXQgZWw3LjEgY2FuJ3Qgc3Vw cG9ydCB0aGUgZmVhdHVyZSBiZWNhdXNlIG9mIGl0cyBsaWJ2aXJ0IHZlcnNpb24gKDEuMi44KSB3 aGlsZSB0aGUgcmVxdWlyZWQgb25lIGlzIDEuMi4xNC4NCj4+Pj4+Pj4+IEkgZGlkbid0IHRlc3Qs IGJ1dCBJIGd1ZXNzIEYyMiBzdXBwb3J0cyBpdC4NCj4+Pj4+Pj4+IElzIHRoZXJlIGFueSBjaGFu Y2UgdGhhdCBlbDcuMiB3b3VsZCBzdXBwb3J0IGl0IHdpdGggYSBiYWNrcG9ydGVkIGxpYnZpcnRk Pw0KPj4+Pj4+PiANCj4+Pj4+Pj4gSXQgZG9lcyBzdXBwb3J0IGl0LCBidXQgb25seSBob3QtcGx1 ZyBub3QgaG90LXVucGx1Zy4NCj4+Pj4+Pj4gIA0KPj4+Pj4+Pj4gT3Igd2lsbCBhIGRlZGljYXRl ZCBsaWJ2aXJ0IHJoZXYgcGFja2FnZSBiZSByZWxlYXNlZCBzbyBhcyB0aGUgZG93bnN0cmVhbSB0 byBzdXBwb3J0IGl0IChsaWtlIHFlbXUta3ZtIGZvciBsaXZlIHNuYXBzaG90IHNvbWUgdGltZSBh Z28pPw0KPj4+Pj4+Pj4gRG9jdW1lbnRhdGlvbiBhbmQgbGltaXRhdGlvbiBvZiB0aGUgbGlidmly dCB2ZXJzaW9uIGZvciBob3QgcGx1ZyBtZW1vcnkgYXJlIGRpZmZpY3VsdCB0byBmaW5kIGluIHRo ZSBvdmlydCB3aWtpIGFuZCBtb3JlIGdlbmVyYWxseSBvbiB0aGUgd2ViLg0KPj4+Pj4+Pj4gTWF5 YmUgdGhlIGZlYXR1cmUgaGFzIGJlZW4gcG9zdHBvbmVkIHRvIGEgMy42LnogcmVsZWFzZT8NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IEkgd29ya3Mgd2l0aCBmZWRvcmEgYW5kIHlvdSBjYW4gdXNlIGl0IGN1 cnJlbnRseSB3aXRoIHRoaXMgZmVhdHVyZS4NCj4+Pj4+PiANCj4+Pj4+PiBJdCB3b3JrcyBvbiBj ZW50b3MgdG9vLCBxZW11LWt2bS1ldiAyLjMgd2UgZGlzdHJpYnV0ZSBpbiBvdmlydCByZXBvDQo+ Pj4+PiBIZWxsbywgbm8gcWVtdS1rdm0tZXYgMi4zIGlzIG5vdCBlbm91Z2g6DQo+Pj4+PiBbcm9v dEBmdWppIH5dIyBxZW11LWltZyAtLXZlcnNpb24NCj4+Pj4+IHFlbXUtaW1nIHZlcnNpb24gMi4z LjAgKHFlbXUta3ZtLWV2LTIuMy4wLTI5LjEuZWw3KSwgQ29weXJpZ2h0IChjKSAyMDA0LTIwMDgg RmFicmljZSBCZWxsYXJkDQo+Pj4+PiBhbmQNCj4+Pj4+IHZkc20tNC4xNy4xMC4xLTAuZWw3LmNl bnRvcy5ub2FyY2gNCj4+Pj4+IA0KPj4+Pj4gSSBnZXQgdGhpcyBlcnJvciBtZXNzYWdlIGVhY2gg dGltZSBJIHRyeSB0byBob3QgYWRkIG1lbW9yeSA6DQo+Pj4+PiBEZWMgIDkgMTE6MTg6MDAgZnVq aSBqb3VybmFsOiB1bnN1cHBvcnRlZCBjb25maWd1cmF0aW9uOiB1bmtub3duIGRldmljZSB0eXBl IOKAmG1lbW9yeScNCj4+Pj4gDQo+Pj4+IHdhcyB0aGUgVk0gc3RhcnRlZCBpbiBhIDMuNiBjbHVz dGVyPw0KPj4+IHN1cmUsIG9uIGEgZnVsbCAzLjYgY2x1c3Rlci4gSSBzdG9wcGVkL3Jlc3RhcnRl ZCB0aGVtLiBJIHJlc3RhcnRlZCB2ZHNtZCBhbmQgbGlidmlydGQNCj4+IA0KPj4gb2suLmFuZCBq dXN0IGZvciB0aGUgc2FrZSBvZiBjb21wbGV0ZW5lc3MgLSB3aGF0IGlzIGxpYnZpcnQgdmVyc2lv biBleGFjdGx5PyBJZiB5b3XigJlyZSBydW5uaW5nIDwxLjIuMTQgdGhlbiB5b3VyIGluaXRpYWwg Y29tbWVudCBtYWtlIGEgbG90IG9mIHNlbnNl4oCmLg0KPj4gWWVzLCBlbDcuMiBoYXMgdGhlIHJp Z2h0IG9uZSAoMS4yLjE3KSBidXQgZXZlbiBvbiA3LjEgaXQgc2hvdWxkIHN1cHBvcnQgaXQgYW5k IGlmIGl0IGRvZXNu4oCZdCBpdOKAmXMgb3VyIHByb2JsZW0gd2Ugc2hvdWxkIGZpeCBpbiBvdmly dCAoc2ltaWxhcmx5IGFzIHdlIHNvbHZlIHFlbXUgYnkgc2hpcHBpbmcgaXQgb3Vyc2VsdmVzKQ0K PiBsaWJ2aXJ0LWRhZW1vbi0xLjIuOC0xNi5lbDdfMS41Lng4Nl82NA0KPiBJJ20gcmVhbGx5IHN1 cnByaXNlZCB0aGF0IHN1Y2ggYSB3YWl0ZWQgZmVhdHVyZSBoYXMgbm90IGJlZW4geWV0IHRlc3Rl ZCBieSB0aGUgY29tbXVuaXR5IHVzZXJzIHdpdGggZWw3LCBzbyB0aGF0IG5vYm9keSBoYXMgcmVw b3J0ZWQgdGhlIGlzc3VlIHlldC4NCg0KV2VpcmQgaW5kZWVkLiBXZWxsLCBSSEVMIDcuMiBpcyBv dXQgZm9yIG1vcmUgdGhhbiBhIG1vbnRoIGFuZCB0aGVyZSBpcyBjZW50b3MgNy4yIGJldGEgYW5k IHBlcmhhcHMgcmMgYXMgd2VsbCwgaXQncyBkdWUgdmVyeSBzb29uDQpTYW5kcm8sIHdlIHNob3Vs ZCB0aGluayBhYm91dCBpdCAtIHNpbmNlIHdlIHB1c2ggcWVtdS1rdm0tZXYgd2UgZG8gbm90IHJl YWxseSBlbmZvcmNlIGFueW9uZSB0byBydW4gb24gZWw3LjIuIFdlIHdhbnQgdG8gZG8gdGhhdCBm b3IgdmFyaW91cyByZWFzb25zIGFzIHNvb24gYXMgcG9zc2libGUuIE1heWJlIHVwZGF0aW5nIHFl bXUta3ZtLWV2IHRvIHJlcXVpcmUgbmV3IDcuMiBsaWJ2aXJ0Pw0KDQo+PiANCj4+Pj4gT3IgaG93 L3doZW4gZGlkIHlvdSBjcmVhdGUgaXQ/DQo+Pj4gdGhvc2Ugdm1zIGhhdmUgYmVlbiBjcmVhdGVk IGJlZm9yZSB1cHJhZGluZyB0byAzLjYsIHNvbWUgb2YgdGhlbSBmcm9tIGEgYmxhbmsgdGVtcGxh dGUsIG90aGVyIG9uZSBiYXNlZCBvbiBhIGVsNyB0ZW1wbGF0ZS4NCj4+Pj4gDQo+Pj4+IFRoYW5r cywNCj4+Pj4gbWljaGFsDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBJIHRyaWVkIHRvIHJlc3RhcnQg dmRzbWQgYnV0IGl0IGlzIHRoZSBzYW1lLCBldmVuIG9uIG90aGVyIGhvc3RzLg0KPj4+Pj4gDQo+ Pj4+PiBhbnkgaGVscCB3aWxsIGJlIGFwcHJlY2lhdGVkLCB0aGFuayB5b3UuDQo+Pj4+Pj4gDQo+ Pj4+Pj4+ICANCj4+Pj4+Pj4+IFRoYW5rIHlvdSBmb3IgeW91ciBoZWxwDQo+Pj4+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gVXNl cnMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBVc2Vyc0BvdmlydC5vcmcNCj4+Pj4+Pj4+IGh0dHA6 Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KPj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBVc2VycyBt YWlsaW5nIGxpc3QNCj4+Pj4+Pj4gVXNlcnNAb3ZpcnQub3JnDQo+Pj4+Pj4+IGh0dHA6Ly9saXN0 cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KPj4+Pj4gDQo+Pj4+PiAtLSANCj4+ Pj4+IE5hdGhhbmHDq2wgQmxhbmNoZXQNCj4+Pj4+IA0KPj4+Pj4gU3VwZXJ2aXNpb24gcsOpc2Vh dQ0KPj4+Pj4gUMO0bGUgSW5mcmFzdHJ1dHVyZXMgSW5mb3JtYXRpcXVlcw0KPj4+Pj4gMjI3IGF2 ZW51ZSBQcm9mZXNzZXVyLUplYW4tTG91aXMtVmlhbGENCj4+Pj4+IDM0MTkzIE1PTlRQRUxMSUVS IENFREVYIDUgCQ0KPj4+Pj4gVMOpbC4gMzMgKDApNCA2NyA1NCA4NCA1NQ0KPj4+Pj4gRmF4ICAz MyAoMCk0IDY3IDU0IDg0IDE0DQo+Pj4+PiBibGFuY2hldEBhYmVzLmZyIA0KPj4+IA0KPj4+IC0t IA0KPj4+IE5hdGhhbmHDq2wgQmxhbmNoZXQNCj4+PiANCj4+PiBTdXBlcnZpc2lvbiByw6lzZWF1 DQo+Pj4gUMO0bGUgSW5mcmFzdHJ1dHVyZXMgSW5mb3JtYXRpcXVlcw0KPj4+IDIyNyBhdmVudWUg UHJvZmVzc2V1ci1KZWFuLUxvdWlzLVZpYWxhDQo+Pj4gMzQxOTMgTU9OVFBFTExJRVIgQ0VERVgg NSAJDQo+Pj4gVMOpbC4gMzMgKDApNCA2NyA1NCA4NCA1NQ0KPj4+IEZheCAgMzMgKDApNCA2NyA1 NCA4NCAxNA0KPj4+IGJsYW5jaGV0QGFiZXMuZnIgDQo+IA0KPiAtLSANCj4gTmF0aGFuYcOrbCBC bGFuY2hldA0KPiANCj4gU3VwZXJ2aXNpb24gcsOpc2VhdQ0KPiBQw7RsZSBJbmZyYXN0cnV0dXJl cyBJbmZvcm1hdGlxdWVzDQo+IDIyNyBhdmVudWUgUHJvZmVzc2V1ci1KZWFuLUxvdWlzLVZpYWxh DQo+IDM0MTkzIE1PTlRQRUxMSUVSIENFREVYIDUgCQ0KPiBUw6lsLiAzMyAoMCk0IDY3IDU0IDg0 IDU1DQo+IEZheCAgMzMgKDApNCA2NyA1NCA4NCAxNA0KPiBibGFuY2hldEBhYmVzLmZyIA0K --Apple-Mail-B756CF2D-7AA7-41EC-8110-C54B216C8099 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+T24gMDkgRGVjIDIwMTUsIGF0IDE4OjA3LCBOYXRoYW5h w6tsIEJsYW5jaGV0ICZsdDs8YSBocmVmPSJtYWlsdG86YmxhbmNoZXRAYWJlcy5mciI+YmxhbmNo ZXRAYWJlcy5mcjwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGRpdj4NCiAgDQogICAgPG1ldGEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04IiBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiPg0KICANCiAgDQogICAgPGJyPg0KICAgIDxi cj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkxlIDA5LzEyLzIwMTUgMTg6MDAs IE1pY2hhbCBTa3JpdmFuZWsgYQ0KICAgICAgw6ljcml0Jm5ic3A7Ojxicj4NCiAgICA8L2Rpdj4N CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6QzJBQTBFMDgtNjcxNC00QzI4LTg3NEQtQjNDOUY5 MzEwMjg4QHJlZGhhdC5jb20iIHR5cGU9ImNpdGUiPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICAgICAg PGJyIGNsYXNzPSIiPg0KICAgICAgPGRpdj4NCiAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQogICAgICAgICAgPGRpdiBjbGFzcz0iIj5PbiAwOSBEZWMgMjAxNSwgYXQg MTc6NTQsIE5hdGhhbmHDq2wgQmxhbmNoZXQNCiAgICAgICAgICAgICZsdDs8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpibGFuY2hldEBhYmVzLmZyIiBjbGFzcz0iIj5ibGFu Y2hldEBhYmVzLmZyPC9hPiZndDsgd3JvdGU6PC9kaXY+DQogICAgICAgICAgPGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSIiPg0KICAg ICAgICAgICAgPG1ldGEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVx dWl2PSJDb250ZW50LVR5cGUiIGNsYXNzPSIiPg0KICAgICAgICAgICAgPGRpdiBiZ2NvbG9yPSIj RkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0iIj4gPGJyIGNsYXNzPSIiPg0KICAgICAgICAg ICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+TGUgMDkvMTIvMjAxNSAxNzoxMiwgTWljaGFsDQogICAgICAgICAgICAgICAgU2tyaXZh bmVrIGEgw6ljcml0Jm5ic3A7OjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNpdGU9Im1pZDowMDg4RkQzMi1BMDY3LTQyNUItQjRE Mi0wMkQzQjgwMkI0RkVAcmVkaGF0LmNvbSIgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQogICAgICAg ICAgICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0 bWw7DQogICAgICAgICAgICAgICAgICBjaGFyc2V0PXV0Zi04IiBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4NCiAg ICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPk9uIDA5IERlYyAyMDE1LCBhdCAxNDo1NCwgTmF0 aGFuYcOrbA0KICAgICAgICAgICAgICAgICAgICAgIEJsYW5jaGV0ICZsdDs8YSBtb3otZG8tbm90 LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpibGFuY2hldEBhYmVzLmZyIiBjbGFzcz0iIj5ibGFu Y2hldEBhYmVzLmZyPC9hPiZndDsNCiAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8L2Rpdj4N CiAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij4NCiAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAg ICAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdiBiZ2Nv bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIiBjbGFzcz0iIj4gPGJyIGNsYXNzPSIiPg0KICAg ICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAg ICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5MZSAwOC8xMi8yMDE1DQogICAgICAgICAg ICAgICAgICAgICAgICAgIDExOjQzLCBNaWNoYWwgU2tyaXZhbmVrIGEgw6ljcml0Jm5ic3A7Ojxi ciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjU5QTk1N0JCLUIyMUYtNDY2Ni1BNTk5 LTJFRDMzM0M4MjAxQ0ByZWRoYXQuY29tIiB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIDA4IERlYyAyMDE1LCBh dCAxMToyMCwgWWFuaXYgRGFyeSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0i bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86eWRhcnlAcmVkaGF0LmNvbSI+ PC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzp5ZGFy eUByZWRoYXQuY29tIj55ZGFyeUByZWRoYXQuY29tPC9hPiZndDsNCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgd3JvdGU6PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij48YnIgY2xhc3M9IiIgY2xlYXI9ImFsbCI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGRpdiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHByZSBjb2xzPSI3MiIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIiBj bGFzcz0iIj5ZYW5pdiBEYXJ5DQpUZWNobmljYWwgUHJvZHVjdCBNYW5hZ2VyDQpSZWQgSGF0IElz cmFlbCBMdGQuDQozNCBKZXJ1c2FsZW0gUm9hZA0KQnVpbGRpbmcgQSwgNHRoIGZsb29yDQpSYSdh bmFuYSwgSXNyYWVsIDQzNTAxMDkNCg0KVGVsIDogKzk3MiAoOSkgNzY5MjMwNg0KICAgICAgICA4 MjcyMzA2DQpFbWFpbDogPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86eWRh cnlAcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnlkYXJ5QHJlZGhhdC5jb208 L2E+DQpJUkMgOiB5ZGFyeTwvc3Bhbj48L3ByZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rp dj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBEZWMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDgsIDIwMTUgYXQgMjowMyBBTSwgTmF0aGFuYcOrbA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmxhbmNoZXQgPHNwYW4gZGlyPSJsdHIiIGNs YXNzPSIiPiZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmst YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpibGFuY2hldEBhYmVzLmZyIj48L2E+PGEgY2xhc3M9 Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmJsYW5jaGV0QGFiZXMuZnIi PmJsYW5jaGV0QGFiZXMuZnI8L2E+Jmd0Ozwvc3Bhbj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHdyb3RlOjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuOGV4O2JvcmRl ci1sZWZ0OjFweCAjY2NjDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPkhpIGFsbCw8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSSBtYXkgbWlzcyBzb21ldGhpbmcgYnV0IGFjY29yZGluZw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byA8YSBtb3otZG8tbm90LXNl bmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cu b3ZpcnQub3JnL0ZlYXR1cmVzL0hvdF9QbHVnX01lbW9yeSI+aHR0cDovL3d3dy5vdmlydC5vcmcv RmVhdHVyZXMvSG90X1BsdWdfTWVtb3J5PC9hPiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgb3ZpcnQgMy42IHdhcyBzdXBwb3NlZCB0byBzdXBwb3J0DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBob3QgcGx1ZyBtZW1vcnkgZmVhdHVyZS4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTm90aGluZyBoYXBwZW5zIGlu IHJlYWxpdHkgd2hlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbmNy ZWFzaW5nIG1lbW9yeSBvbiBhIHJ1bm5pbmcgdm0NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2l0aCBjZW50b3M3LjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSSBmb3VuZCB0aGlzIDogPGEgbW96LWRvLW5vdC1zZW5kPSJ0 cnVlIiBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JncGlwZXJtYWlsL2tpbWNoaS1kZXZlbC8y MDE1LUp1bmUvMDEwNzE0Lmh0bWwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNs YXNzPSIiPjwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8v bGlzdHMub3ZpcnQub3JncGlwZXJtYWlsL2tpbWNoaS1kZXZlbC8yMDE1LUp1bmUvMDEwNzE0Lmh0 bWwiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmdwaXBlcm1haWwva2ltY2hpLWRldmVsLzIwMTUtSnVu ZS8wMTA3MTQuaHRtbDwvYT4sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGFuZCBpdCBzZWVtcyB0aGF0IGVsNy4xIGNhbid0DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHN1cHBvcnQgdGhlIGZlYXR1cmUgYmVjYXVzZSBvZiBpdHMNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlidmlydCB2ZXJzaW9uICgxLjIuOCkgd2hp bGUgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcXVpcmVkIG9u ZSBpcyAxLjIuMTQuPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBJIGRpZG4ndCB0ZXN0LCBidXQgSSBndWVzcyBGMjINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydHMgaXQuPGJyIGNsYXNzPSIiPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJcyB0aGVyZSBhbnkgY2hhbmNlIHRoYXQgZWw3 LjINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd291bGQgc3VwcG9ydCBp dCB3aXRoIGEgYmFja3BvcnRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBsaWJ2aXJ0ZD88YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBj bGFzcz0iIj5JdCBkb2VzIHN1cHBvcnQgaXQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGJ1dCBvbmx5IGhvdC1wbHVnIG5vdCBob3QtdW5wbHVnLjxiciBjbGFzcz0iIj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPiBPciB3aWxsIGENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVkaWNhdGVkIGxpYnZpcnQgcmhldiBw YWNrYWdlIGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlbGVhc2Vk IHNvIGFzIHRoZSBkb3duc3RyZWFtIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN1cHBvcnQgaXQgKGxpa2UgcWVtdS1rdm0gZm9yIGxpdmUNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc25hcHNob3Qgc29tZSB0aW1lIGFnbyk/PGJyIGNsYXNz PSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEb2N1bWVudGF0aW9u IGFuZCBsaW1pdGF0aW9uIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRoZSBsaWJ2aXJ0IHZlcnNpb24gZm9yIGhvdCBwbHVnDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG1lbW9yeSBhcmUgZGlmZmljdWx0IHRvIGZpbmQgaW4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIG92aXJ0IHdpa2kgYW5kIG1vcmUgZ2Vu ZXJhbGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9uIHRoZSB3ZWIu PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXli ZSB0aGUgZmVhdHVyZSBoYXMgYmVlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBwb3N0cG9uZWQgdG8gYSAzLjYueiByZWxlYXNlPzxiciBjbGFzcz0iIj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPkkgd29ya3Mgd2l0aCBmZWRvcmENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHlvdSBjYW4gdXNlIGl0IGN1cnJl bnRseSB3aXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgZmVh dHVyZS48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg PC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIEl0IHdvcmtzIG9uIGNlbnRvcyB0b28s IHFlbXUta3ZtLWV2IDIuMyB3ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBkaXN0cmlidXRl IGluIG92aXJ0IHJlcG88L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICBIZWxs bywgbm8gcWVtdS1rdm0tZXYgMi4zIGlzIG5vdCBlbm91Z2g6PGJyIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgW3Jvb3RAZnVqaSB+XSMgcWVtdS1pbWcgLS12ZXJzaW9uPGJyIGNs YXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgcWVtdS1pbWcgdmVyc2lvbiAyLjMuMA0K ICAgICAgICAgICAgICAgICAgICAgICAgKHFlbXUta3ZtLWV2LTIuMy4wLTI5LjEuZWw3KSwgQ29w eXJpZ2h0IChjKQ0KICAgICAgICAgICAgICAgICAgICAgICAgMjAwNC0yMDA4IEZhYnJpY2UgQmVs bGFyZDxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIGFuZDxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIHZkc20tNC4xNy4xMC4xLTAuZWw3LmNlbnRvcy5u b2FyY2g8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YnIgY2xhc3M9IiI+ DQogICAgICAgICAgICAgICAgICAgICAgICBJIGdldCB0aGlzIGVycm9yIG1lc3NhZ2UgZWFjaCB0 aW1lIEkgdHJ5IHRvIGhvdA0KICAgICAgICAgICAgICAgICAgICAgICAgYWRkIG1lbW9yeSA6PGJy IGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgRGVjJm5ic3A7IDkgMTE6MTg6MDAg ZnVqaSBqb3VybmFsOiB1bnN1cHBvcnRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgY29uZmln dXJhdGlvbjogdW5rbm93biBkZXZpY2UgdHlwZSDigJhtZW1vcnknPGJyIGNsYXNzPSIiPg0KICAg ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAg ICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgIDxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICB3YXMgdGhlIFZNIHN0YXJ0ZWQgaW4gYSAzLjYgY2x1c3Rlcj8gPGJyIGNsYXNzPSIi Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQog ICAgICAgICAgICAgIHN1cmUsIG9uIGEgZnVsbCAzLjYgY2x1c3Rlci4gSSBzdG9wcGVkL3Jlc3Rh cnRlZCB0aGVtLiBJDQogICAgICAgICAgICAgIHJlc3RhcnRlZCB2ZHNtZCBhbmQgbGlidmlydGQ8 YnIgY2xhc3M9IiI+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICA8ZGl2PjxiciBjbGFzcz0iIj4NCiAgICAgICAgPC9k aXY+DQogICAgICAgIG9rLi5hbmQganVzdCBmb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzIC0g d2hhdCBpcyBsaWJ2aXJ0DQogICAgICAgIHZlcnNpb24gZXhhY3RseT8gSWYgeW914oCZcmUgcnVu bmluZyAmbHQ7MS4yLjE0IHRoZW4geW91ciBpbml0aWFsDQogICAgICAgIGNvbW1lbnQgbWFrZSBh IGxvdCBvZiBzZW5zZeKApi48L2Rpdj4NCiAgICAgIDxkaXY+WWVzLCBlbDcuMiBoYXMgdGhlIHJp Z2h0IG9uZSAoMS4yLjE3KSBidXQgZXZlbiBvbiA3LjEgaXQNCiAgICAgICAgc2hvdWxkIHN1cHBv cnQgaXQgYW5kIGlmIGl0IGRvZXNu4oCZdCBpdOKAmXMgb3VyIHByb2JsZW0gd2Ugc2hvdWxkDQog ICAgICAgIGZpeCBpbiBvdmlydCAoc2ltaWxhcmx5IGFzIHdlIHNvbHZlIHFlbXUgYnkgc2hpcHBp bmcgaXQNCiAgICAgICAgb3Vyc2VsdmVzKTxicj4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2tx dW90ZT4NCiAgICBsaWJ2aXJ0LWRhZW1vbi0xLjIuOC0xNi5lbDdfMS41Lng4Nl82NDxicj4NCiAg ICBJJ20gcmVhbGx5IHN1cnByaXNlZCB0aGF0IHN1Y2ggYSB3YWl0ZWQgZmVhdHVyZSBoYXMgbm90 IGJlZW4geWV0DQogICAgdGVzdGVkIGJ5IHRoZSBjb21tdW5pdHkgdXNlcnMgd2l0aCBlbDcsIHNv IHRoYXQgbm9ib2R5IGhhcyByZXBvcnRlZA0KICAgIHRoZSBpc3N1ZSB5ZXQuPGJyPjwvZGl2Pjwv YmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5XZWlyZCBpbmRlZWQuIFdlbGwsIFJIRUwgNy4yIGlz IG91dCBmb3IgbW9yZSB0aGFuIGEgbW9udGggYW5kIHRoZXJlIGlzIGNlbnRvcyA3LjIgYmV0YSBh bmQgcGVyaGFwcyByYyBhcyB3ZWxsLCBpdCdzIGR1ZSB2ZXJ5IHNvb248ZGl2PlNhbmRybywgd2Ug c2hvdWxkIHRoaW5rIGFib3V0IGl0IC0gc2luY2Ugd2UgcHVzaCBxZW11LWt2bS1ldiB3ZSBkbyBu b3QgcmVhbGx5IGVuZm9yY2UgYW55b25lIHRvIHJ1biBvbiBlbDcuMi4gV2Ugd2FudCB0byBkbyB0 aGF0IGZvciB2YXJpb3VzIHJlYXNvbnMgYXMgc29vbiBhcyBwb3NzaWJsZS4gTWF5YmUgdXBkYXRp bmcgcWVtdS1rdm0tZXYgdG8gcmVxdWlyZSBuZXcgNy4yIGxpYnZpcnQ/PC9kaXY+PGRpdj48YnI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6 QzJBQTBFMDgtNjcxNC00QzI4LTg3NEQtQjNDOUY5MzEwMjg4QHJlZGhhdC5jb20iIHR5cGU9ImNp dGUiPg0KICAgICAgPGRpdj48YnIgY2xhc3M9IiI+DQogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KICAgICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAgICA8 ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiIGNsYXNzPSIiPg0KICAgICAgICAg ICAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MDA4OEZEMzItQTA2Ny00MjVCLUI0RDItMDJEM0I4 MDJCNEZFQHJlZGhhdC5jb20iIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAg IDxkaXYgY2xhc3M9IiI+T3IgaG93L3doZW4gZGlkIHlvdSBjcmVhdGUgaXQ/PC9kaXY+DQogICAg ICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgdGhvc2Ugdm1zIGhhdmUgYmVl biBjcmVhdGVkIGJlZm9yZSB1cHJhZGluZyB0byAzLjYsIHNvbWUNCiAgICAgICAgICAgICAgb2Yg dGhlbSBmcm9tIGEgYmxhbmsgdGVtcGxhdGUsIG90aGVyIG9uZSBiYXNlZCBvbiBhIGVsNw0KICAg ICAgICAgICAgICB0ZW1wbGF0ZS48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgIDxibG9ja3F1 b3RlIGNpdGU9Im1pZDowMDg4RkQzMi1BMDY3LTQyNUItQjREMi0wMkQzQjgwMkI0RkVAcmVkaGF0 LmNvbSIgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAg PGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0i Ij5taWNoYWw8L2Rpdj4NCiAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K ICAgICAgICAgICAgICAgICAgICA8ZGl2IGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAg IDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgY2xhc3M9IiI+IDxiciBjbGFz cz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIEkgdHJpZWQgdG8gcmVzdGFydCB2ZHNtZCBi dXQgaXQgaXMgdGhlIHNhbWUsDQogICAgICAgICAgICAgICAgICAgICAgICBldmVuIG9uIG90aGVy IGhvc3RzLjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxiciBjbGFzcz0i Ij4NCiAgICAgICAgICAgICAgICAgICAgICAgIGFueSBoZWxwIHdpbGwgYmUgYXBwcmVjaWF0ZWQs IHRoYW5rIHlvdS48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICA8YmxvY2tx dW90ZSBjaXRlPSJtaWQ6NTlBOTU3QkItQjIxRi00NjY2LUE1OTktMkVEMzMzQzgyMDFDQHJlZGhh dC5jb20iIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXYgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPiBUaGFuaw0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHlvdSBmb3IgeW91ciBoZWxwPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xh c3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVXNlcnMgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOlVzZXJzQG92aXJ0 Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPlVzZXJzQG92aXJ0Lm9yZzwvYT48YnIgY2xh c3M9IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGEgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0 dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VyczwvYT48YnIgY2xhc3M9 IiI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIGNsYXNzPSIiPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iIj5Vc2VycyBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 c3BhbiBjbGFzcz0iIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpVc2Vy c0BvdmlydC5vcmciIGNsYXNzPSIiPlVzZXJzQG92aXJ0Lm9yZzwvYT48L3NwYW4+PGJyIGNsYXNz PSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iIj48YSBt b3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1h bi9saXN0aW5mby91c2VycyIgY2xhc3M9IiI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFu L2xpc3RpbmZvL3VzZXJzPC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L2Jsb2Nr cXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAg ICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgPGJyIGNsYXNz PSIiPg0KICAgICAgICAgICAgICAgICAgICAgICAgPHByZSBjbGFzcz0ibW96LXNpZ25hdHVyZSIg Y29scz0iNzIiPi0tIA0KTmF0aGFuYcOrbCBCbGFuY2hldA0KDQpTdXBlcnZpc2lvbiByw6lzZWF1 DQpQw7RsZSBJbmZyYXN0cnV0dXJlcyBJbmZvcm1hdGlxdWVzDQoyMjcgYXZlbnVlIFByb2Zlc3Nl dXItSmVhbi1Mb3Vpcy1WaWFsYQ0KMzQxOTMgTU9OVFBFTExJRVIgQ0VERVggNSAJDQpUw6lsLiAz MyAoMCk0IDY3IDU0IDg0IDU1DQpGYXggIDMzICgwKTQgNjcgNTQgODQgMTQNCjxhIG1vei1kby1u b3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFp bHRvOmJsYW5jaGV0QGFiZXMuZnIiPmJsYW5jaGV0QGFiZXMuZnI8L2E+IDwvcHJlPg0KICAgICAg ICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICA8YnIgY2xhc3M9IiI+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAg ICAgICAgICAgICAgPGJyIGNsYXNzPSIiPg0KICAgICAgICAgICAgICA8cHJlIGNsYXNzPSJtb3ot c2lnbmF0dXJlIiBjb2xzPSI3MiI+LS0gDQpOYXRoYW5hw6tsIEJsYW5jaGV0DQoNClN1cGVydmlz aW9uIHLDqXNlYXUNClDDtGxlIEluZnJhc3RydXR1cmVzIEluZm9ybWF0aXF1ZXMNCjIyNyBhdmVu dWUgUHJvZmVzc2V1ci1KZWFuLUxvdWlzLVZpYWxhDQozNDE5MyBNT05UUEVMTElFUiBDRURFWCA1 IAkNClTDqWwuIDMzICgwKTQgNjcgNTQgODQgNTUNCkZheCAgMzMgKDApNCA2NyA1NCA4NCAxNA0K PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVk IiBocmVmPSJtYWlsdG86YmxhbmNoZXRAYWJlcy5mciI+YmxhbmNoZXRAYWJlcy5mcjwvYT4gPC9w cmU+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgPC9ibG9j a3F1b3RlPg0KICAgICAgPC9kaXY+DQogICAgICA8YnIgY2xhc3M9IiI+DQogICAgPC9ibG9ja3F1 b3RlPg0KICAgIDxicj4NCiAgICA8cHJlIGNsYXNzPSJtb3otc2lnbmF0dXJlIiBjb2xzPSI3MiI+ LS0gDQpOYXRoYW5hw6tsIEJsYW5jaGV0DQoNClN1cGVydmlzaW9uIHLDqXNlYXUNClDDtGxlIElu ZnJhc3RydXR1cmVzIEluZm9ybWF0aXF1ZXMNCjIyNyBhdmVudWUgUHJvZmVzc2V1ci1KZWFuLUxv dWlzLVZpYWxhDQozNDE5MyBNT05UUEVMTElFUiBDRURFWCA1IAkNClTDqWwuIDMzICgwKTQgNjcg NTQgODQgNTUNCkZheCAgMzMgKDApNCA2NyA1NCA4NCAxNA0KPGEgY2xhc3M9Im1vei10eHQtbGlu ay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmJsYW5jaGV0QGFiZXMuZnIiPmJsYW5jaGV0QGFi ZXMuZnI8L2E+IDwvcHJlPg0KICANCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48 L2h0bWw+ --Apple-Mail-B756CF2D-7AA7-41EC-8110-C54B216C8099--

I too verified the problem with CentOS 7.1 Hypervisor and CentOS 7.1 VM BTW: I find the below window somehow misleading when you try te resize the memory of the vm https://drive.google.com/file/d/0BwoPbcrMv8mvbUw2VnpCMTNNQlU/view?usp=sharin... Gianluca

On Wed, Dec 9, 2015 at 8:04 PM, Michal Skrivanek <mskrivan@redhat.com> wrote:
On 09 Dec 2015, at 18:07, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 09/12/2015 18:00, Michal Skrivanek a écrit :
On 09 Dec 2015, at 17:54, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 09/12/2015 17:12, Michal Skrivanek a écrit :
On 09 Dec 2015, at 14:54, Nathanaël Blanchet <blanchet@abes.fr> wrote:
Le 08/12/2015 11:43, Michal Skrivanek a écrit :
On 08 Dec 2015, at 11:20, Yaniv Dary < <ydary@redhat.com>ydary@redhat.com> wrote:
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathanaël Blanchet < <blanchet@abes.fr> blanchet@abes.fr> wrote:
Hi all,
I may miss something but according to http://www.ovirt.org/Features/Hot_Plug_Memory, ovirt 3.6 was supposed to support the hot plug memory feature. Nothing happens in reality when increasing memory on a running vm with centos7. I found this : <http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html> http://lists.ovirt.orgpipermail/kimchi-devel/2015-June/010714.html, and it seems that el7.1 can't support the feature because of its libvirt version (1.2.8) while the required one is 1.2.14. I didn't test, but I guess F22 supports it. Is there any chance that el7.2 would support it with a backported libvirtd?
It does support it, but only hot-plug not hot-unplug.
Or will a dedicated libvirt rhev package be released so as the downstream to support it (like qemu-kvm for live snapshot some time ago)? Documentation and limitation of the libvirt version for hot plug memory are difficult to find in the ovirt wiki and more generally on the web. Maybe the feature has been postponed to a 3.6.z release?
I works with fedora and you can use it currently with this feature.
It works on centos too, qemu-kvm-ev 2.3 we distribute in ovirt repo
Hello, no qemu-kvm-ev 2.3 is not enough: [root@fuji ~]# qemu-img --version qemu-img version 2.3.0 (qemu-kvm-ev-2.3.0-29.1.el7), Copyright (c) 2004-2008 Fabrice Bellard and vdsm-4.17.10.1-0.el7.centos.noarch
I get this error message each time I try to hot add memory : Dec 9 11:18:00 fuji journal: unsupported configuration: unknown device type ‘memory'
was the VM started in a 3.6 cluster?
sure, on a full 3.6 cluster. I stopped/restarted them. I restarted vdsmd and libvirtd
ok..and just for the sake of completeness - what is libvirt version exactly? If you’re running <1.2.14 then your initial comment make a lot of sense…. Yes, el7.2 has the right one (1.2.17) but even on 7.1 it should support it and if it doesn’t it’s our problem we should fix in ovirt (similarly as we solve qemu by shipping it ourselves)
libvirt-daemon-1.2.8-16.el7_1.5.x86_64 I'm really surprised that such a waited feature has not been yet tested by the community users with el7, so that nobody has reported the issue yet.
the feature has been tested (by me) and bug was already reported (here https://bugzilla.redhat.com/show_bug.cgi?id=1287994 )
Weird indeed. Well, RHEL 7.2 is out for more than a month and there is centos 7.2 beta and perhaps rc as well, it's due very soon Sandro, we should think about it - since we push qemu-kvm-ev we do not really enforce anyone to run on el7.2. We want to do that for various reasons as soon as possible. Maybe updating qemu-kvm-ev to require new 7.2 libvirt?
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/.
Or how/when did you create it?
those vms have been created before uprading to 3.6, some of them from a blank template, other one based on a el7 template.
Thanks, michal
I tried to restart vdsmd but it is the same, even on other hosts.
any help will be appreciated, thank you.
Thank you for your help _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@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 14blanchet@abes.fr
-- 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 14blanchet@abes.fr
-- 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 14blanchet@abes.fr
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

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@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 * extras: centos.fastbull.org * ovirt-3.6: ftp.nluug.nl * ovirt-3.6-epel: epel.besthosting.ua * updates: 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: 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 I then shutdown the VM and power on it again and I get the changed memory: $ 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@internal. Dec 9, 2015 11:56:19 PM VM racclient1 configuration was updated by admin@internal. Dec 9, 2015 11:56:18 PM Hotset memory: changed the amount of memory on VM racclient1 from 8192 to 10240 It doesn't seem as expected, does it? Gianluca

On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi@gmail.com> = wrote: =20 On Wed, Dec 9, 2015 at 10:21 PM, Sandro Bonazzola wrote: =20 =20 No idea. If it's libvirt issue, can you test = http://cbs.centos.org/koji/buildinfo?buildID=3D4726 = <http://cbs.centos.org/koji/buildinfo?buildID=3D4726> ? it's from centos = virt sig, introduced for Xen but should work on kvm as well. or the 7.2 =
=20 =20 =20 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. =20 On hypervisor I shutdown VM, put maintenance global and shutdown = engine VM. Then [root@ractor ~]# yum --enablerepo=3Dcr update libvirt* Loaded plugins: fastestmirror, langpacks cr = | 3.4 kB 00:00:00 =20 cr/7/x86_64/primary_db = | 3.7 MB 00:00:02 =20 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 =
--> Processing Dependency: libsystemd.so.0()(64bit) for package: =
---> 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-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 =3D 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 =3D 208-20.el7_1.6 for =
---> 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 =3D 7:1.02.93-3.el7_1.1 for =
---> 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 =3D 208-20.el7_1.6 for package: = systemd-sysv-208-20.el7_1.6.x86_64 --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package: = systemd-python-208-20.el7_1.6.x86_64 --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package: =
---> Package systemd.x86_64 0:219-19.el7 will be an update --> Processing Dependency: kmod >=3D 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 =3D 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 =3D = 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 =3D 7:2.02.115-3.el7_1.1 for =
--Apple-Mail=_D07768CA-8F60-41D9-9659-347CA26627F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 libvirt from http://mirror.centos.org/centos/7/cr/x86_64/Packages/ = <http://mirror.centos.org/centos/7/cr/x86_64/Packages/>. package: libvirt-client-1.2.17-13.el7_2.2.x86_64 libvirt-client-1.2.17-13.el7_2.2.x86_64 package: libvirt-daemon-driver-storage-1.2.17-13.el7_2.2.x86_64 package: systemd-208-20.el7_1.6.x86_64 package: 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64 libgudev1-208-20.el7_1.6.x86_64 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 >=3D 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 =3D 033-241.el7_1.5 for package: = dracut-config-rescue-033-241.el7_1.5.x86_64 --> Processing Dependency: dracut =3D 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 =20 Dependencies Resolved =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Package Arch Version = Repository Size = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
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 =20 Transaction Summary = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Upgrade 15 Packages (+15 Dependent packages) =20 Total download size: 17 M Is this ok [y/d/N]:=20 =20 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 =20 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) =20 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?
=20 Dec 9 23:56:18 racclient1 kernel: init_memory_mapping: [mem = 0x240000000-0x2bfffffff] =20 ANd output of dmesg contains: =20 [ 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 =E2=80=9Cfree=E2=80=9D sstill shows the same value as before = hotplug?
=20 I then shutdown the VM and power on it again and I get the changed = memory:
well, yeah, but that doesn=E2=80=99t count since you=E2=80=99ve 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 =20 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@internal.
hm..doesn=E2=80=99t sound right. Did the confirmation window show any = more fields as changed other than memory?
=20 Dec 9, 2015 11:56:19 PM VM racclient1 configuration was updated by admin@internal.
that=E2=80=99s correct - the new base for the next run
=20 Dec 9, 2015 11:56:18 PM =20 Hotset memory: changed the amount of memory on VM racclient1 from 8192 = to 10240
that=E2=80=99s the actual hotplug
=20 It doesn't seem as expected, does it?
I think we=E2=80=99re almost there. Just need to figure out what = happened in the guest. I would suspect a problem there Thanks, michal
Gianluca =20
<div class=3D""><div class=3D"h5"><div class=3D""><br = class=3D""></div><div class=3D""><br = class=3D""></div></div></div></div></div></div></blockquote></div><br = class=3D"">Hello,<br class=3D"">tried on a test environment where I have = 3.6.0 on single CentOS 7.1 hypervisor configured with = SelfHostedEngine<br class=3D"">I have a CentOS 7.1 vm running.<br = class=3D""><br class=3D"">On hypervisor I shutdown VM, put maintenance = global and shutdown engine VM.<br class=3D"">Then<br = class=3D"">[root@ractor ~]# yum --enablerepo=3Dcr update libvirt*<br = class=3D"">Loaded plugins: fastestmirror, langpacks<br = class=3D"">cr &= nbsp; &nb= sp;  = ; &= nbsp; &nb= sp;  = ; | 3.4 kB 00:00:00 <br = class=3D"">cr/7/x86_64/primary_db  = ; &= nbsp; &nb= sp;  = ; | 3.7 = MB 00:00:02 <br class=3D"">Loading mirror = speeds from cached hostfile<br class=3D""> * base: <a =
--Apple-Mail=_D07768CA-8F60-41D9-9659-347CA26627F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 10 Dec 2015, at 00:11, Gianluca Cecchi <<a = href=3D"mailto:gianluca.cecchi@gmail.com" = class=3D"">gianluca.cecchi@gmail.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, = Dec 9, 2015 at 10:21 PM, Sandro Bonazzola <span dir=3D"ltr" = class=3D""></span> wrote:<br class=3D""><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr" class=3D""><br = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span = class=3D""><div class=3D""><br class=3D""></div></span><div class=3D"">No = idea. If it's libvirt issue, can you test <a = href=3D"http://cbs.centos.org/koji/buildinfo?buildID=3D4726" = target=3D"_blank" = class=3D"">http://cbs.centos.org/koji/buildinfo?buildID=3D4726</a> ? = it's from centos virt sig, introduced for Xen but should work on kvm as = well. or the 7.2 libvirt from <a = href=3D"http://mirror.centos.org/centos/7/cr/x86_64/Packages/" = target=3D"_blank" = class=3D"">http://mirror.centos.org/centos/7/cr/x86_64/Packages/</a>.</div= href=3D"http://centos.fastbull.org/" class=3D"">centos.fastbull.org</a><br= class=3D""> * extras: <a href=3D"http://centos.fastbull.org/" = class=3D"">centos.fastbull.org</a><br class=3D""> * ovirt-3.6: <a = href=3D"http://ftp.nluug.nl/" class=3D"">ftp.nluug.nl</a><br = class=3D""> * ovirt-3.6-epel: <a href=3D"http://epel.besthosting.ua/"= class=3D"">epel.besthosting.ua</a><br class=3D""> * updates: <a = href=3D"http://centos.copahost.com/" class=3D"">centos.copahost.com</a><br= class=3D"">Resolving Dependencies<br class=3D"">--> Running = transaction check<br class=3D"">---> Package libvirt-client.x86_64 = 0:1.2.8-16.el7_1.5 will be updated<br class=3D"">---> Package = libvirt-client.x86_64 0:1.2.17-13.el7_2.2 will be an update<br = class=3D"">--> Processing Dependency: = libsystemd.so.0(LIBSYSTEMD_209)(64bit) for package: = libvirt-client-1.2.17-13.el7_2.2.x86_64<br class=3D"">--> Processing = Dependency: libsystemd.so.0()(64bit) for package: = libvirt-client-1.2.17-13.el7_2.2.x86_64<br class=3D"">---> Package = libvirt-daemon.x86_64 0:1.2.8-16.el7_1.5 will be updated<br = class=3D"">---> Package libvirt-daemon.x86_64 0:1.2.17-13.el7_2.2 = will be an update<br class=3D"">---> Package = libvirt-daemon-config-nwfilter.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-config-nwfilter.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package = libvirt-daemon-driver-interface.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-driver-interface.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package = libvirt-daemon-driver-network.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-driver-network.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package = libvirt-daemon-driver-nodedev.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-driver-nodedev.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package = libvirt-daemon-driver-nwfilter.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-driver-nwfilter.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package libvirt-daemon-driver-qemu.x86_64 = 0:1.2.8-16.el7_1.5 will be updated<br class=3D"">---> Package = libvirt-daemon-driver-qemu.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package libvirt-daemon-driver-secret.x86_64 = 0:1.2.8-16.el7_1.5 will be updated<br class=3D"">---> Package = libvirt-daemon-driver-secret.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">---> Package = libvirt-daemon-driver-storage.x86_64 0:1.2.8-16.el7_1.5 will be = updated<br class=3D"">---> Package = libvirt-daemon-driver-storage.x86_64 0:1.2.17-13.el7_2.2 will be an = update<br class=3D"">--> 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<br = class=3D"">---> Package libvirt-daemon-kvm.x86_64 0:1.2.8-16.el7_1.5 = will be updated<br class=3D"">---> Package libvirt-daemon-kvm.x86_64 = 0:1.2.17-13.el7_2.2 will be an update<br class=3D"">---> Package = libvirt-lock-sanlock.x86_64 0:1.2.8-16.el7_1.5 will be updated<br = class=3D"">---> Package libvirt-lock-sanlock.x86_64 = 0:1.2.17-13.el7_2.2 will be an update<br class=3D"">---> Package = libvirt-python.x86_64 0:1.2.8-7.el7_1.1 will be updated<br = class=3D"">---> Package libvirt-python.x86_64 0:1.2.17-2.el7 will be = an update<br class=3D"">--> Running transaction check<br = class=3D"">---> Package device-mapper-libs.x86_64 7:1.02.93-3.el7_1.1 = will be updated<br class=3D"">--> Processing Dependency: = device-mapper-libs =3D 7:1.02.93-3.el7_1.1 for package: = 7:device-mapper-1.02.93-3.el7_1.1.x86_64<br class=3D"">---> Package = device-mapper-libs.x86_64 7:1.02.107-5.el7 will be an update<br = class=3D"">---> Package systemd-libs.x86_64 0:208-20.el7_1.6 will be = updated<br class=3D"">--> Processing Dependency: systemd-libs =3D = 208-20.el7_1.6 for package: systemd-208-20.el7_1.6.x86_64<br = class=3D"">---> Package systemd-libs.x86_64 0:219-19.el7 will be an = update<br class=3D"">--> Running transaction check<br = class=3D"">---> Package device-mapper.x86_64 7:1.02.93-3.el7_1.1 will = be updated<br class=3D"">--> Processing Dependency: device-mapper =3D = 7:1.02.93-3.el7_1.1 for package: = 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64<br class=3D"">---> = Package device-mapper.x86_64 7:1.02.107-5.el7 will be an update<br = class=3D"">---> Package systemd.x86_64 0:208-20.el7_1.6 will be = updated<br class=3D"">--> Processing Dependency: systemd =3D = 208-20.el7_1.6 for package: systemd-sysv-208-20.el7_1.6.x86_64<br = class=3D"">--> Processing Dependency: systemd =3D 208-20.el7_1.6 for = package: systemd-python-208-20.el7_1.6.x86_64<br class=3D"">--> = Processing Dependency: systemd =3D 208-20.el7_1.6 for package: = libgudev1-208-20.el7_1.6.x86_64<br class=3D"">---> Package = systemd.x86_64 0:219-19.el7 will be an update<br class=3D"">--> = Processing Dependency: kmod >=3D 18-4 for package: = systemd-219-19.el7.x86_64<br class=3D"">--> Running transaction = check<br class=3D"">---> Package device-mapper-event.x86_64 = 7:1.02.93-3.el7_1.1 will be updated<br class=3D"">--> Processing = Dependency: device-mapper-event =3D 7:1.02.93-3.el7_1.1 for package: = 7:lvm2-libs-2.02.115-3.el7_1.1.x86_64<br class=3D"">---> Package = device-mapper-event.x86_64 7:1.02.107-5.el7 will be an update<br = class=3D"">--> Processing Dependency: device-mapper-event-libs =3D = 7:1.02.107-5.el7 for package: = 7:device-mapper-event-1.02.107-5.el7.x86_64<br class=3D"">---> = Package kmod.x86_64 0:14-10.el7 will be updated<br class=3D"">---> = Package kmod.x86_64 0:20-5.el7 will be an update<br class=3D"">---> = Package libgudev1.x86_64 0:208-20.el7_1.6 will be updated<br = class=3D"">---> Package libgudev1.x86_64 0:219-19.el7 will be an = update<br class=3D"">---> Package systemd-python.x86_64 = 0:208-20.el7_1.6 will be updated<br class=3D"">---> Package = systemd-python.x86_64 0:219-19.el7 will be an update<br class=3D"">--->= Package systemd-sysv.x86_64 0:208-20.el7_1.6 will be updated<br = class=3D"">---> Package systemd-sysv.x86_64 0:219-19.el7 will be an = update<br class=3D"">--> Running transaction check<br = class=3D"">---> Package device-mapper-event-libs.x86_64 = 7:1.02.93-3.el7_1.1 will be updated<br class=3D"">---> Package = device-mapper-event-libs.x86_64 7:1.02.107-5.el7 will be an update<br = class=3D"">---> Package lvm2-libs.x86_64 7:2.02.115-3.el7_1.1 will be = updated<br class=3D"">--> Processing Dependency: lvm2-libs =3D = 7:2.02.115-3.el7_1.1 for package: 7:lvm2-2.02.115-3.el7_1.1.x86_64<br = class=3D"">---> Package lvm2-libs.x86_64 7:2.02.130-5.el7 will be an = update<br class=3D"">--> Running transaction check<br = class=3D"">---> Package lvm2.x86_64 7:2.02.115-3.el7_1.1 will be = updated<br class=3D"">---> Package lvm2.x86_64 7:2.02.130-5.el7 will = be an update<br class=3D"">--> Processing Dependency: = device-mapper-persistent-data >=3D 0.5.5-1 for package: = 7:lvm2-2.02.130-5.el7.x86_64<br class=3D"">--> Running transaction = check<br class=3D"">---> Package device-mapper-persistent-data.x86_64 = 0:0.4.1-2.el7 will be updated<br class=3D"">---> Package = device-mapper-persistent-data.x86_64 0:0.5.5-1.el7 will be an update<br = class=3D"">--> Processing Conflict: systemd-219-19.el7.x86_64 = conflicts initscripts < 9.49.28-1<br class=3D"">--> Restarting = Dependency Resolution with new changes.<br class=3D"">--> Running = transaction check<br class=3D"">---> Package initscripts.x86_64 = 0:9.49.24-1.el7 will be updated<br class=3D"">---> Package = initscripts.x86_64 0:9.49.30-1.el7 will be an update<br class=3D"">--> = Processing Conflict: systemd-219-19.el7.x86_64 conflicts dracut < = 033-243<br class=3D"">--> Restarting Dependency Resolution with new = changes.<br class=3D"">--> Running transaction check<br = class=3D"">---> Package dracut.x86_64 0:033-241.el7_1.5 will be = updated<br class=3D"">--> Processing Dependency: dracut =3D = 033-241.el7_1.5 for package: = dracut-config-rescue-033-241.el7_1.5.x86_64<br class=3D"">--> = Processing Dependency: dracut =3D 033-241.el7_1.5 for package: = dracut-network-033-241.el7_1.5.x86_64<br class=3D"">---> Package = dracut.x86_64 0:033-360.el7_2 will be an update<br class=3D"">--> = Running transaction check<br class=3D"">---> Package = dracut-config-rescue.x86_64 0:033-241.el7_1.5 will be updated<br = class=3D"">---> Package dracut-config-rescue.x86_64 0:033-360.el7_2 = will be an update<br class=3D"">---> Package dracut-network.x86_64 = 0:033-241.el7_1.5 will be updated<br class=3D"">---> Package = dracut-network.x86_64 0:033-360.el7_2 will be an update<br = class=3D"">--> Finished Dependency Resolution<br class=3D""><br = class=3D"">Dependencies Resolved<br class=3D""><br = class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D<br = class=3D""> Package &n= bsp; &nbs= p; = Arch = Version &= nbsp; Repository Size<br = class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D<br class=3D"">Updating:<br = class=3D""> dracut &nb= sp;  = ; = x86_64 = 033-360.el7_2 &= nbsp; cr 311 = k<br = class=3D""> initscripts &nbs= p; = = x86_64 = 9.49.30-1.el7 &= nbsp; cr 429 = k<br = class=3D""> libvirt-client &= nbsp; &nb= sp; = x86_64 = 1.2.17-13.el7_2.2 = cr 4.3 M<br = class=3D""> libvirt-daemon &= nbsp; &nb= sp; = x86_64 = 1.2.17-13.el7_2.2 = cr 584 k<br = class=3D""> libvirt-daemon-config-nwfilter &nb= sp; = x86_64 = 1.2.17-13.el7_2.2 = cr 121 k<br = class=3D""> libvirt-daemon-driver-interface &n= bsp; = x86_64 = 1.2.17-13.el7_2.2 = cr 161 k<br = class=3D""> libvirt-daemon-driver-network &nbs= p; = x86_64 = 1.2.17-13.el7_2.2 = cr 301 k<br = class=3D""> libvirt-daemon-driver-nodedev &nbs= p; = x86_64 = 1.2.17-13.el7_2.2 = cr 160 k<br = class=3D""> libvirt-daemon-driver-nwfilter &nb= sp; = x86_64 = 1.2.17-13.el7_2.2 = cr 184 k<br = class=3D""> libvirt-daemon-driver-qemu &= nbsp; = x86_64 = 1.2.17-13.el7_2.2 = cr 569 k<br = class=3D""> libvirt-daemon-driver-secret  = ; = x86_64 = 1.2.17-13.el7_2.2 = cr 154 k<br = class=3D""> libvirt-daemon-driver-storage &nbs= p; = x86_64 = 1.2.17-13.el7_2.2 = cr 327 k<br = class=3D""> libvirt-daemon-kvm &nb= sp;  = ; x86_64 = 1.2.17-13.el7_2.2 = cr 117 k<br = class=3D""> libvirt-lock-sanlock &= nbsp; &nb= sp; x86_64 = 1.2.17-13.el7_2.2 = cr 166 k<br = class=3D""> libvirt-python &= nbsp; &nb= sp; = x86_64 = 1.2.17-2.el7 &n= bsp; = cr 309 k<br = class=3D"">Updating for dependencies:<br = class=3D""> device-mapper &n= bsp; &nbs= p; = x86_64 = 7:1.02.107-5.el7 &nbs= p; cr 251 k<br = class=3D""> device-mapper-event &n= bsp; &nbs= p; x86_64 = 7:1.02.107-5.el7 &nbs= p; cr 167 k<br = class=3D""> device-mapper-event-libs &nb= sp; = x86_64 = 7:1.02.107-5.el7 &nbs= p; cr 169 k<br = class=3D""> device-mapper-libs &nb= sp;  = ; x86_64 = 7:1.02.107-5.el7 &nbs= p; cr 304 k<br = class=3D""> device-mapper-persistent-data &nbs= p; = x86_64 = 0.5.5-1.el7 &nb= sp; = cr 350 k<br = class=3D""> dracut-config-rescue &= nbsp; &nb= sp; x86_64 = 033-360.el7_2 &= nbsp; = cr 49 k<br = class=3D""> dracut-network &= nbsp; &nb= sp; = x86_64 = 033-360.el7_2 &= nbsp; = cr 90 k<br = class=3D""> kmod  = ; &= nbsp; &nb= sp; x86_64 = 20-5.el7 = = cr 114 k<br = class=3D""> libgudev1 = &n= bsp; = x86_64 = 219-19.el7 &nbs= p; = cr 64 k<br = class=3D""> lvm2  = ; &= nbsp; &nb= sp; x86_64 = 7:2.02.130-5.el7 &nbs= p; cr 1.0 M<br = class=3D""> lvm2-libs = &n= bsp; = x86_64 = 7:2.02.130-5.el7 &nbs= p; cr 872 k<br = class=3D""> systemd &n= bsp; &nbs= p; = x86_64 = 219-19.el7 &nbs= p; = cr 5.1 M<br = class=3D""> systemd-libs &nb= sp;  = ; = x86_64 = 219-19.el7 &nbs= p; = cr 356 k<br = class=3D""> systemd-python &= nbsp; &nb= sp; = x86_64 = 219-19.el7 &nbs= p; = cr 97 k<br = class=3D""> systemd-sysv &nb= sp;  = ; = x86_64 = 219-19.el7 &nbs= p; = cr 52 k<br = class=3D""><br class=3D"">Transaction Summary<br = class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D<br class=3D"">Upgrade 15 Packages (+15 Dependent = packages)<br class=3D""><br class=3D"">Total download size: 17 M<br = class=3D"">Is this ok [y/d/N]: <br class=3D""><br class=3D"">Then I = reboot my HV, exit from maintenance, connect to engine and start VM.<br = class=3D"">VM situation<br class=3D"">$ free<br = class=3D""> &nb= sp; total = used = free shared buff/cache = available<br class=3D"">Mem: = 8172900 147356 = 7875692 = 8480 149852 = 7847248<br class=3D"">Swap: = 839676 = 0 839676<br class=3D""><br = class=3D""></div><div class=3D"gmail_extra">I set memory from 8192Mb to = 10240Mb<br class=3D""></div><div class=3D"gmail_extra">I get the same = window I got with previous libvirt version.<br class=3D""></div><div = class=3D"gmail_extra">I select OK (I don't select "Apply later" = checkbox)<br class=3D""></div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">Inside guest there is no = changed memory, but I can see this in /var/log/messages:<br = class=3D""></div></div></div></blockquote><div><br class=3D""></div>could = it be perhaps the guest has troubles recognizing hotplug? Is it also a = CentOS 7.1 guest?</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><br class=3D"">Dec 9 23:56:18 racclient1 = kernel: init_memory_mapping: [mem 0x240000000-0x2bfffffff]<br = class=3D""><br class=3D""></div><div class=3D"gmail_extra">ANd output of = dmesg contains:<br class=3D""></div><div class=3D"gmail_extra"><br = class=3D"">[ 219.363640] ACPI: \_SB_.MP00: = ACPI_NOTIFY_DEVICE_CHECK event<br class=3D"">[ 219.364248] = init_memory_mapping: [mem 0x240000000-0x2bfffffff]<br class=3D"">[ = 219.364253] [mem 0x240000000-0x2bfffffff] page 2M<br = class=3D"">[ 219.366773] [ffffea0009000000-ffffea00091fffff] = PMD -> [ffff8800b7e00000-ffff8800b7ffffff] on node 0<br = class=3D"">[ 219.368433] [ffffea0009200000-ffffea00093fffff] = PMD -> [ffff880231400000-ffff8802315fffff] on node 0<br = class=3D"">[ 219.369838] [ffffea0009400000-ffffea00095fffff] = PMD -> [ffff880233600000-ffff8802337fffff] on node 0<br = class=3D"">[ 219.371226] [ffffea0009600000-ffffea00097fffff] = PMD -> [ffff880233000000-ffff8802331fffff] on node 0<br = class=3D"">[ 219.372790] [ffffea0009800000-ffffea00099fffff] = PMD -> [ffff880232c00000-ffff880232dfffff] on node 0<br = class=3D"">[ 219.374185] [ffffea0009a00000-ffffea0009bfffff] = PMD -> [ffff880232200000-ffff8802323fffff] on node 0<br = class=3D"">[ 219.377349] [ffffea0009c00000-ffffea0009ffffff] = PMD -> [ffff8800b7400000-ffff8800b77fffff] on node 0<br = class=3D"">[ 219.378716] [ffffea000a000000-ffffea000a1fffff] = PMD -> [ffff8800b7000000-ffff8800b71fffff] on node 0<br = class=3D"">[ 219.380115] [ffffea000a200000-ffffea000a3fffff] = PMD -> [ffff880230c00000-ffff880230dfffff] on node 0<br = class=3D"">[ 219.388147] [ffffea000a400000-ffffea000abfffff] = PMD -> [ffff880227c00000-ffff8802283fffff] on node 0<br = class=3D"">[ 219.389687] [ffffea000ac00000-ffffea000adfffff] = PMD -> [ffff8800b7200000-ffff8800b73fffff] on node 0<br = class=3D""></div></div></div></blockquote><div><br class=3D""></div>but = =E2=80=9Cfree=E2=80=9D sstill shows the same value as before = hotplug?</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><br class=3D"">I then shutdown the VM and power on = it again and I get the changed memory:<br = class=3D""></div></div></div></blockquote><div><br class=3D""></div>well, = yeah, but that doesn=E2=80=99t count since you=E2=80=99ve shut it down, = so the next run is initialized with 10GB</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra">$ free<br = class=3D""> &nb= sp; total = used = free shared buff/cache = available<br class=3D"">Mem: = 10237276 167872 = 9919656 = 8480 149748 = 9891280<br class=3D"">Swap: = 839676 = 0 839676<br class=3D""><br = class=3D""></div><div class=3D"gmail_extra">BTW: When I press ok in the = gui for memory increase I get these events in webadmin:<br class=3D"">Dec = 9, 2015 11:56:22 PM<br class=3D"">VM racclient1 c71_Disk1_newtemplate = disk was updated by admin@internal.<br = class=3D""></div></div></div></blockquote><div><br = class=3D""></div>hm..doesn=E2=80=99t sound right. Did the confirmation = window show any more fields as changed other than memory?</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"> <br = class=3D"">Dec 9, 2015 11:56:19 PM<br class=3D"">VM racclient1 = configuration was updated by admin@internal.<br = class=3D""></div></div></div></blockquote><div><br = class=3D""></div>that=E2=80=99s correct - the new base for the next = run</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"> <br class=3D"">Dec 9, 2015 = 11:56:18 PM <br class=3D"">Hotset memory: changed the amount of = memory on VM racclient1 from 8192 to 10240<br = class=3D""></div></div></div></blockquote><div><br = class=3D""></div>that=E2=80=99s the actual hotplug</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">It doesn't seem as expected, = does it?<br class=3D""></div></div></div></blockquote><div><br = class=3D""></div>I think we=E2=80=99re almost there. Just need to figure = out what happened in the guest. I would suspect a problem = there</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra">Gianluca<br = class=3D""></div><div class=3D"gmail_extra"><br class=3D""></div></div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_D07768CA-8F60-41D9-9659-347CA26627F5--

On Thu, Dec 10, 2015 at 10:41 AM, Michal Skrivanek <mskrivan@redhat.com> wrote:
On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi@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/.
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?
Yes, CentOS 7.1 updated up to a couple of days ago.
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?
Yes, output of "free" command show the same amount of memory
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
It was only to verify that after shutdown/power on the changed setting would have been applied to the VM
$ 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@internal.
hm..doesn’t sound right. Did the confirmation window show any more fields as changed other than memory?
The window I got when I increased the amount of memory was the same as in a previous test where I selected "Cancel", before libvirt update; see https://drive.google.com/file/d/0BwoPbcrMv8mvbUw2VnpCMTNNQlU/view?usp=sharin... And I also commented about misleading information inside it: I didn't clearly understand what would have been changed and what not, because I see memory information in both parts.....
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
Thanks, michal
Gianluca
The gui events have the same timestamp of the moment when I pressed ok. After 2-3 minutes I did shutdown and power on of the VM and I only got the down/up events... I'm available to make further test you need. GIanluca

On 10 Dec 2015, at 11:30, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Dec 10, 2015 at 10:41 AM, Michal Skrivanek <mskrivan@redhat.com> wrote:
On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi@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/.
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?
Yes, CentOS 7.1 updated up to a couple of days ago.
Can you try 7.2? I don’t remember exactly but it may be that in earlier guests it’s not automatic. Check some tips for onlining memory explicitly 5.2. How to online memory ------------ Even if the memory is hot-added, it is not at ready-to-use state. For using newly added memory, you have to "online" the memory block. For onlining, you have to write "online" to the memory block's state file as: % echo online > /sys/devices/system/memory/memoryXXX/state
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?
Yes, output of "free" command show the same amount of memory
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
It was only to verify that after shutdown/power on the changed setting would have been applied to the VM
$ 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@internal.
hm..doesn’t sound right. Did the confirmation window show any more fields as changed other than memory?
The window I got when I increased the amount of memory was the same as in a previous test where I selected "Cancel", before libvirt update; see https://drive.google.com/file/d/0BwoPbcrMv8mvbUw2VnpCMTNNQlU/view?usp=sharin...
And I also commented about misleading information inside it: I didn't clearly understand what would have been changed and what not, because I see memory information in both parts…..
I agree it’s confusing. Please do open a bug on that Thanks, michal
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
Thanks, michal
Gianluca
The gui events have the same timestamp of the moment when I pressed ok. After 2-3 minutes I did shutdown and power on of the VM and I only got the down/up events... I'm available to make further test you need.
GIanluca

On Thu, Dec 10, 2015 at 12:24 PM, Michal Skrivanek <mskrivan@redhat.com> wrote:
Yes, CentOS 7.1 updated up to a couple of days ago.
Can you try 7.2? I don’t remember exactly but it may be that in earlier guests it’s not automatic. Check some tips for onlining memory explicitly
5.2. How to online memory ------------ Even if the memory is hot-added, it is not at ready-to-use state. For using newly added memory, you have to "online" the memory block.
For onlining, you have to write "online" to the memory block's state file as:
% echo online > /sys/devices/system/memory/memoryXXX/state
Hello, with your suggestions it worked as expected, without updating any packages in VM 7.1 guest (I seemed to remember that the forced online operation should not be necessary any more...): Starting state with 10Gb of ram inside the VM [root@racclient1 ~]# ll -d /sys/devices/system/memory/memory* | wc -l 80 slots defined: 0 --> 23 32 --> 87 Increase from web gui memory from 10240 to 12288 I see this in messages as expected Dec 10 12:59:32 racclient1 kernel: init_memory_mapping: [mem 0x2c0000000-0x33fffffff] In /sys/devices/system/memory I see 16 new memoryxx directories (probably each one addressing 128Mb...) 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 They have indeed been added but are offline, eg latest previous one: [root@racclient1 ~]# cat /sys/devices/system/memory/memory87/state online first newly added one: [root@racclient1 ~]# cat /sys/devices/system/memory/memory88/state offline [root@racclient1 ~]# cat /sys/devices/system/memory/memory87/online 1 [root@racclient1 ~]# cat /sys/devices/system/memory/memory88/online 0 put online the new segments: [root@racclient1 ~]# for i in $(seq 88 103)
do echo online > /sys/devices/system/memory/memory${i}/state done
Memory has been increased now, also from inside the OS. [root@racclient1 ~]# free total used free shared buff/cache available Mem: 12334428 222080 11934044 8480 178304 12019544 NOTE: no new entries after online memory, neither in messages file nor in dmesg output. Questions: 1) which component to bugzilla against for message confusing window of the gui? 2) Initially I see that my VM (in webadmin gui) has 8Gb of defined memory AND 8Gb of "Physical Memory Guaranteed". After increasing memory, the second one remains the same and doesn't change even after shutdown / Power on. I think it could be an enhancement to ask the user if he/she wants to change it too, instead of manually go through Edit --> resource allocation --> memory allocation screen If seen as a agreed enhancement, which components to bugzilla against for RFE? Gianluca

--Apple-Mail=_969CE17C-EAA3-4702-836D-32D271E3A43E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Dec 2015, at 13:16, Gianluca Cecchi <gianluca.cecchi@gmail.com> = wrote: >=20 > On Thu, Dec 10, 2015 at 12:24 PM, Michal Skrivanek = <mskrivan@redhat.com <mailto:mskrivan@redhat.com>> wrote: >=20 >=20 > > > > Yes, CentOS 7.1 updated up to a couple of days ago. >=20 > Can you try 7.2? I don=E2=80=99t remember exactly but it may be that = in earlier guests it=E2=80=99s not automatic. Check some tips for = onlining memory explicitly >=20 > 5.2. How to online memory > ------------ > Even if the memory is hot-added, it is not at ready-to-use state. > For using newly added memory, you have to "online" the memory block. >=20 > For onlining, you have to write "online" to the memory block's state = file as: >=20 > % echo online > /sys/devices/system/memory/memoryXXX/state >=20 > =20 >=20 > Hello, > with your suggestions it worked as expected, without updating any = packages in VM 7.1 guest (I seemed to remember that the forced online = operation should not be necessary any more=E2=80=A6): great! with 7.2 it should be automatic. I think with Windows it works = automatically as well. >=20 > Starting state with 10Gb of ram inside the VM > [root@racclient1 ~]# ll -d /sys/devices/system/memory/memory* | wc -l > 80 >=20 > slots defined: > 0 --> 23 > 32 --> 87 >=20 > Increase from web gui memory from 10240 to 12288 >=20 > I see this in messages as expected >=20 > Dec 10 12:59:32 racclient1 kernel: init_memory_mapping: [mem = 0x2c0000000-0x33fffffff] >=20 > In /sys/devices/system/memory I see 16 new memoryxx directories = (probably each one addressing 128Mb...) >=20 > 88 > 89 > 90 > 91 > 92 > 93 > 94 > 95 > 96 > 97 > 98 > 99 > 100 > 101 > 102 > 103 >=20 > They have indeed been added but are offline, eg >=20 > latest previous one: > [root@racclient1 ~]# cat /sys/devices/system/memory/memory87/state=20 > online >=20 > first newly added one: > [root@racclient1 ~]# cat /sys/devices/system/memory/memory88/state=20 > offline >=20 > [root@racclient1 ~]# cat /sys/devices/system/memory/memory87/online=20 > 1 > [root@racclient1 ~]# cat /sys/devices/system/memory/memory88/online=20 > 0 >=20 > put online the new segments: > [root@racclient1 ~]# for i in $(seq 88 103) > > do > > echo online > /sys/devices/system/memory/memory${i}/state > > done >=20 > Memory has been increased now, also from inside the OS. >=20 > [root@racclient1 ~]# free > total used free shared buff/cache = available > Mem: 12334428 222080 11934044 8480 178304 = 12019544 >=20 >=20 > NOTE: no new entries after online memory, neither in messages file nor = in dmesg output. >=20 > Questions: > 1) which component to bugzilla against for message confusing window of = the gui? doesn=E2=80=99t matter much, ovirt-engine, frontend. > 2) Initially I see that my VM (in webadmin gui) has 8Gb of defined = memory AND 8Gb of "Physical Memory Guaranteed". > After increasing memory, the second one remains the same and doesn't = change even after shutdown / Power on. > I think it could be an enhancement to ask the user if he/she wants to = change it too, instead of manually go through=20 > Edit --> resource allocation --> memory allocation screen > If seen as a agreed enhancement, which components to bugzilla against = for RFE? yeah, these are two separate fields. The suggestion sounds reasonable to = me, Roy, thoughts on that? > Gianluca --Apple-Mail=_969CE17C-EAA3-4702-836D-32D271E3A43E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 10 Dec 2015, at 13:16, Gianluca Cecchi <<a = href=3D"mailto:gianluca.cecchi@gmail.com" = class=3D"">gianluca.cecchi@gmail.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, = Dec 10, 2015 at 12:24 PM, Michal Skrivanek <span dir=3D"ltr" = class=3D""><<a href=3D"mailto:mskrivan@redhat.com" target=3D"_blank" = class=3D"">mskrivan@redhat.com</a>></span> wrote:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= -style:solid;padding-left:1ex"><span class=3D""><br class=3D""><br = class=3D""> ><br class=3D""> > Yes, CentOS 7.1 updated up to a couple of days ago.<br class=3D""> <br class=3D""> </span>Can you try 7.2? I don=E2=80=99t remember exactly but it may be = that in earlier guests it=E2=80=99s not automatic. Check some tips for = onlining memory explicitly<br class=3D""> <br class=3D""> 5.2. How to online memory<br class=3D""> ------------<br class=3D""> Even if the memory is hot-added, it is not at ready-to-use state.<br = class=3D""> For using newly added memory, you have to "online" the memory block.<br = class=3D""> <br class=3D""> For onlining, you have to write "online" to the memory block's state = file as:<br class=3D""> <br class=3D""> % echo online > /sys/devices/system/memory/memoryXXX/state<br = class=3D""> <div class=3D""><div class=3D"h5"><br = class=3D""></div></div></blockquote><div class=3D""> </div></div><br = class=3D""></div><div class=3D"gmail_extra">Hello,</div><div = class=3D"gmail_extra">with your suggestions it worked as expected, = without updating any packages in VM 7.1 guest (I seemed to remember that = the forced online operation should not be necessary any = more=E2=80=A6):</div></div></div></blockquote><div><br = class=3D""></div>great!</div><div>with 7.2 it should be automatic. I = think with Windows it works automatically as well.</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">Starting state with 10Gb of = ram inside the VM</div><div class=3D"gmail_extra"><div = class=3D"gmail_extra">[root@racclient1 ~]# ll -d = /sys/devices/system/memory/memory* | wc -l</div><div = class=3D"gmail_extra">80</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">slots defined:</div><div = class=3D"gmail_extra">0 --> 23</div><div class=3D"gmail_extra">32 = --> 87</div><div class=3D"gmail_extra"><br class=3D""></div><div = class=3D"gmail_extra">Increase from web gui memory from 10240 to = 12288</div><div class=3D"gmail_extra"><br class=3D""></div><div = class=3D"gmail_extra">I see this in messages as expected</div><div = class=3D"gmail_extra"><br class=3D""></div><div class=3D"gmail_extra">Dec = 10 12:59:32 racclient1 kernel: init_memory_mapping: [mem = 0x2c0000000-0x33fffffff]</div><div class=3D"gmail_extra"><br = class=3D""></div><div = class=3D"gmail_extra">In /sys/devices/system/memory I see 16 new = memoryxx directories (probably each one addressing 128Mb...)</div><div = class=3D"gmail_extra"><br class=3D""></div><div = class=3D"gmail_extra">88</div><div class=3D"gmail_extra">89</div><div = class=3D"gmail_extra">90</div><div class=3D"gmail_extra">91</div><div = class=3D"gmail_extra">92</div><div class=3D"gmail_extra">93</div><div = class=3D"gmail_extra">94</div><div class=3D"gmail_extra">95</div><div = class=3D"gmail_extra">96</div><div class=3D"gmail_extra">97</div><div = class=3D"gmail_extra">98</div><div class=3D"gmail_extra">99</div><div = class=3D"gmail_extra">100</div><div class=3D"gmail_extra">101</div><div = class=3D"gmail_extra">102</div><div class=3D"gmail_extra">103</div><div = class=3D"gmail_extra"><br class=3D""></div><div class=3D"gmail_extra">They= have indeed been added but are offline, eg</div><div = class=3D"gmail_extra"><br class=3D""></div><div = class=3D"gmail_extra">latest previous one:</div><div = class=3D"gmail_extra">[root@racclient1 ~]# cat = /sys/devices/system/memory/memory87/state </div><div = class=3D"gmail_extra">online</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">first newly added = one:</div><div class=3D"gmail_extra">[root@racclient1 ~]# cat = /sys/devices/system/memory/memory88/state </div><div = class=3D"gmail_extra">offline</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">[root@racclient1 ~]# cat = /sys/devices/system/memory/memory87/online </div><div = class=3D"gmail_extra">1</div><div class=3D"gmail_extra">[root@racclient1 = ~]# cat /sys/devices/system/memory/memory88/online </div><div = class=3D"gmail_extra">0</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">put online the new = segments:</div><div class=3D"gmail_extra">[root@racclient1 ~]# for i in = $(seq 88 103)</div><div class=3D"gmail_extra">> do</div><div = class=3D"gmail_extra">> echo online > = /sys/devices/system/memory/memory${i}/state</div><div = class=3D"gmail_extra">> done</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">Memory has been increased = now, also from inside the OS.</div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra">[root@racclient1 ~]# = free</div><div class=3D"gmail_extra"> = total used = free shared buff/cache = available</div><div class=3D"gmail_extra">Mem: = 12334428 222080 11934044 = 8480 178304 = 12019544</div><div class=3D""><br class=3D""></div><div = class=3D""><br class=3D""></div><div class=3D"">NOTE: no new entries = after online memory, neither in messages file nor in dmesg = output.</div><div class=3D""><br class=3D""></div><div = class=3D"">Questions:</div><div class=3D"">1) which component to = bugzilla against for message confusing window of the = gui?</div></div></div></div></blockquote><div><br = class=3D""></div>doesn=E2=80=99t matter much, ovirt-engine, = frontend.</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"">2) Initially I see that my VM (in = webadmin gui) has 8Gb of defined memory AND 8Gb of "Physical Memory = Guaranteed".</div><div class=3D"">After increasing memory, the second = one remains the same and doesn't change even after shutdown / Power = on.</div></div></div></div></blockquote></div><div><blockquote = type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"">I think it could be an enhancement = to ask the user if he/she wants to change it too, instead of manually go = through </div><div class=3D"">Edit --> resource allocation = --> memory allocation screen</div><div class=3D"">If seen as a agreed = enhancement, which components to bugzilla against for = RFE?</div></div></div></div></blockquote><div><br = class=3D""></div><div>yeah, these are two separate fields. The = suggestion sounds reasonable to me, Roy, thoughts on that?</div><div = class=3D""><br class=3D""></div><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"">Gianluca</div></div></div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_969CE17C-EAA3-4702-836D-32D271E3A43E--

On Thu, Dec 10, 2015 at 2:35 PM, Michal Skrivanek <mskrivan@redhat.com> wrote:
great! with 7.2 it should be automatic. I think with Windows it works automatically as well.
In the mean time I tested how to make it automatic also in my CentOS 7.1 guest. I temporarily added this rule inside /lib/udev/rules.d/55-ovirt-guest-agent.rules (but it could have also been a plain new file for that matter): SUBSYSTEM=="memory", ACTION=="add", TEST=="state", ATTR{state}=="offline", ATTR{state}="online" With this row the addition is automatically intercepted and applied from the OS too. Tested changing from 8Gb to 10Gb of ram. I'm not an udev guru.... I took inspiration form the already set up file for cpu adition in 40-redhat.rules file.. ;-) So perhaps the only change in 7.2 is an addition like mine in 40-redhat.rules?
Questions: 1) which component to bugzilla against for message confusing window of the gui?
doesn’t matter much, ovirt-engine, frontend.
Ok, I'll do
Gianluca

--Apple-Mail=_4763F427-94C6-455A-AB71-46D55D1C50F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8
On 10 Dec 2015, at 15:12, Gianluca Cecchi <gianluca.cecchi@gmail.com> = wrote: =20 On Thu, Dec 10, 2015 at 2:35 PM, Michal Skrivanek <mskrivan@redhat.com = <mailto:mskrivan@redhat.com>> wrote: =20 =20 great! with 7.2 it should be automatic. I think with Windows it works = automatically as well. =20 =20 In the mean time I tested how to make it automatic also in my CentOS = 7.1 guest. =20 I temporarily added this rule inside = /lib/udev/rules.d/55-ovirt-guest-agent.rules (but it could have also = been a plain new file for that matter): =20 SUBSYSTEM=3D=3D"memory", ACTION=3D=3D"add", TEST=3D=3D"state", = ATTR{state}=3D=3D"offline", ATTR{state}=3D"online" =20 With this row the addition is automatically intercepted and applied = from the OS too. Tested changing from 8Gb to 10Gb of ram. =20 I'm not an udev guru.... I took inspiration form the already set up = file for cpu adition in 40-redhat.rules file.. ;-)
me neither, but yeah, it=E2=80=99s in 7.2 just like that:) # cat /lib/udev/rules.d/40-redhat.rules # do not edit this file, it will be overwritten on update # CPU hotadd request SUBSYSTEM=3D=3D"cpu", ACTION=3D=3D"add", TEST=3D=3D"online", = ATTR{online}=3D=3D"0", ATTR{online}=3D"1" # Memory hotadd request SUBSYSTEM=3D=3D"memory", ACTION=3D=3D"add", ATTR{state}=3D=3D"offline", = ATTR{state}=3D"online" # reload sysctl.conf / sysctl.conf.d settings when the bridge module is = loaded ACTION=3D=3D"add", SUBSYSTEM=3D=3D"module", KERNEL=3D=3D"bridge", = RUN+=3D"/usr/lib/systemd/systemd-sysctl --prefix=3D/proc/sys/net/bridge" # load SCSI generic (sg) driver SUBSYSTEM=3D=3D"scsi", ENV{DEVTYPE}=3D=3D"scsi_device", = TEST!=3D"[module/sg]", RUN+=3D"/sbin/modprobe -bv sg" # Rule for prandom character device node permissions KERNEL=3D=3D"prandom", MODE=3D=E2=80=9C0644"
=20 So perhaps the only change in 7.2 is an addition like mine in = 40-redhat.rules? =20
=20 =20 Questions: 1) which component to bugzilla against for message confusing window = of the gui? =20 doesn=E2=80=99t matter much, ovirt-engine, frontend. =20 Ok, I'll do =20 =20 Gianluca
--Apple-Mail=_4763F427-94C6-455A-AB71-46D55D1C50F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 10 Dec 2015, at 15:12, Gianluca Cecchi <<a = href=3D"mailto:gianluca.cecchi@gmail.com" = class=3D"">gianluca.cecchi@gmail.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Thu, = Dec 10, 2015 at 2:35 PM, Michal Skrivanek <span dir=3D"ltr" = class=3D""><<a href=3D"mailto:mskrivan@redhat.com" target=3D"_blank" = class=3D"">mskrivan@redhat.com</a>></span> wrote:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= -style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word" = class=3D""><br class=3D""><div class=3D""><div class=3D""><br = class=3D""></div>great!</div><div class=3D"">with 7.2 it should be = automatic. I think with Windows it works automatically as = well.</div><div class=3D""><div class=3D""><div class=3D"h5"><br = class=3D""></div></div></div></div></blockquote><div class=3D""><br = class=3D""></div><div class=3D""><div class=3D"gmail_extra">In the mean = time I tested how to make it automatic also in my CentOS 7.1 = guest.</div><div class=3D"gmail_extra"><br class=3D""></div><div = class=3D"gmail_extra">I temporarily added this rule = inside /lib/udev/rules.d/55-ovirt-guest-agent.rules (but it could = have also been a plain new file for that matter):</div><div = class=3D"gmail_extra"><br class=3D""></div><div class=3D"gmail_extra"><div= class=3D"gmail_extra">SUBSYSTEM=3D=3D"memory", ACTION=3D=3D"add", = TEST=3D=3D"state", ATTR{state}=3D=3D"offline", = ATTR{state}=3D"online"</div><div class=3D""><br class=3D""></div><div = class=3D"">With this row the addition is automatically intercepted and = applied from the OS too.</div><div class=3D"">Tested changing from 8Gb = to 10Gb of ram.</div><div class=3D""><br class=3D""></div><div = class=3D"">I'm not an udev guru.... I took inspiration form the already = set up file for cpu adition in 40-redhat.rules file.. = ;-)</div></div></div></div></div></div></div></blockquote><div><br = class=3D""></div>me neither, but yeah, it=E2=80=99s in 7.2 just like = that:)</div><div><br class=3D""></div><div><div># cat = /lib/udev/rules.d/40-redhat.rules</div><div># do not edit this file, it = will be overwritten on update</div><div><br class=3D""></div><div># CPU = hotadd request</div><div>SUBSYSTEM=3D=3D"cpu", ACTION=3D=3D"add", = TEST=3D=3D"online", ATTR{online}=3D=3D"0", = ATTR{online}=3D"1"</div><div><br class=3D""></div><div># Memory hotadd = request</div><div>SUBSYSTEM=3D=3D"memory", ACTION=3D=3D"add", = ATTR{state}=3D=3D"offline", ATTR{state}=3D"online"</div><div><br = class=3D""></div><div># reload sysctl.conf / sysctl.conf.d settings when = the bridge module is loaded</div><div>ACTION=3D=3D"add", = SUBSYSTEM=3D=3D"module", KERNEL=3D=3D"bridge", = RUN+=3D"/usr/lib/systemd/systemd-sysctl = --prefix=3D/proc/sys/net/bridge"</div><div><br class=3D""></div><div># = load SCSI generic (sg) driver</div><div>SUBSYSTEM=3D=3D"scsi", = ENV{DEVTYPE}=3D=3D"scsi_device", TEST!=3D"[module/sg]", = RUN+=3D"/sbin/modprobe -bv sg"</div><div><br class=3D""></div><div># = Rule for prandom character device node = permissions</div><div>KERNEL=3D=3D"prandom", MODE=3D=E2=80=9C0644"</div><d= iv><br class=3D""></div><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><div class=3D""><div class=3D"gmail_extra"><div = class=3D""><br class=3D""></div><div class=3D"">So perhaps the only = change in 7.2 is an addition like mine in = 40-redhat.rules?</div></div></div><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= -style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word" = class=3D""><div class=3D""><div class=3D""><div class=3D"h5"><blockquote = type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><br class=3D""></div><div class=3D"gmail_extra"><br = class=3D""></div><div class=3D"gmail_extra"><div = class=3D"">Questions:</div><div class=3D"">1) which component to = bugzilla against for message confusing window of the = gui?</div></div></div></div></blockquote><div class=3D""><br = class=3D""></div></div></div>doesn=E2=80=99t matter much, ovirt-engine, = frontend.</div></div></blockquote><div class=3D""><br = class=3D""></div><div class=3D"">Ok, I'll do</div><div class=3D""><br = class=3D""></div><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left= -style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word" = class=3D""><span class=3D""><div = class=3D""></div></span></div></blockquote></div></div>Gianluca</div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_4763F427-94C6-455A-AB71-46D55D1C50F8--

This is a multi-part message in MIME format. --------------080701070002030103070807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Le 10/12/2015 10:41, Michal Skrivanek a =E9crit :
On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi@gmail.com=20 <mailto:gianluca.cecchi@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=3D4726 ? 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=20 hypervisor configured with SelfHostedEngine I have a CentOS 7.1 vm running.
On hypervisor I shutdown VM, put maintenance global and shutdown=20 engine VM. Then [root@ractor ~]# yum --enablerepo=3Dcr 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 upda=
te
--> Processing Dependency: libsystemd.so.0(LIBSYSTEMD_209)(64bit) for=20 package: libvirt-client-1.2.17-13.el7_2.2.x86_64 --> Processing Dependency: libsystemd.so.0()(64bit) for package:=20 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 upda= te ---> Package libvirt-daemon-config-nwfilter.x86_64 0:1.2.8-16.el7_1.5=20 will be updated ---> Package libvirt-daemon-config-nwfilter.x86_64=20 0:1.2.17-13.el7_2.2 will be an update ---> Package libvirt-daemon-driver-interface.x86_64=20 0:1.2.8-16.el7_1.5 will be updated ---> Package libvirt-daemon-driver-interface.x86_64=20 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=20 will be updated ---> Package libvirt-daemon-driver-network.x86_64 0:1.2.17-13.el7_2.2=20 will be an update ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.8-16.el7_1.5=20 will be updated ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.17-13.el7_2.2=20 will be an update ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.2.8-16.el7_1.5=20 will be updated ---> Package libvirt-daemon-driver-nwfilter.x86_64=20 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=20 will be updated ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.2.17-13.el7_2.2=20 will be an update ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.8-16.el7_1.5=20 will be updated ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.17-13.el7_2.2=20 will be an update ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.8-16.el7_1.5=20 will be updated ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.17-13.el7_2.2=20 will be an update --> Processing Dependency: libdevmapper.so.1.02(DM_1_02_97)(64bit)=20 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 upda= ted ---> Package libvirt-daemon-kvm.x86_64 0:1.2.17-13.el7_2.2 will be an=20 update ---> Package libvirt-lock-sanlock.x86_64 0:1.2.8-16.el7_1.5 will be=20 updated ---> Package libvirt-lock-sanlock.x86_64 0:1.2.17-13.el7_2.2 will be=20 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=20 updated --> Processing Dependency: device-mapper-libs =3D 7:1.02.93-3.el7_1.1=20 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 upd= ate ---> Package systemd-libs.x86_64 0:208-20.el7_1.6 will be updated --> Processing Dependency: systemd-libs =3D 208-20.el7_1.6 for package= :=20 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 =3D 7:1.02.93-3.el7_1.1 for=20 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 =3D 208-20.el7_1.6 for package:=20 systemd-sysv-208-20.el7_1.6.x86_64 --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package:=20 systemd-python-208-20.el7_1.6.x86_64 --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package:=20 libgudev1-208-20.el7_1.6.x86_64 ---> Package systemd.x86_64 0:219-19.el7 will be an update --> Processing Dependency: kmod >=3D 18-4 for package:=20 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=20 updated --> Processing Dependency: device-mapper-event =3D 7:1.02.93-3.el7_1.1= =20 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=20 update --> Processing Dependency: device-mapper-event-libs =3D=20 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=20 be updated ---> Package device-mapper-event-libs.x86_64 7:1.02.107-5.el7 will be=20 an update ---> Package lvm2-libs.x86_64 7:2.02.115-3.el7_1.1 will be updated --> Processing Dependency: lvm2-libs =3D 7:2.02.115-3.el7_1.1 for=20 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 >=3D 0.5.5-1=20 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=20 be updated ---> Package device-mapper-persistent-data.x86_64 0:0.5.5-1.el7 will=20 be an update --> Processing Conflict: systemd-219-19.el7.x86_64 conflicts=20 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 <=20 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 =3D 033-241.el7_1.5 for package:=20 dracut-config-rescue-033-241.el7_1.5.x86_64 --> Processing Dependency: dracut =3D 033-241.el7_1.5 for package:=20 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=20 updated ---> Package dracut-config-rescue.x86_64 0:033-360.el7_2 will be an=20 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Package Arch=20 Version Repository Size =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Updating: dracut x86_64=20 033-360.el7_2 cr 311 k initscripts x86_64=20 9.49.30-1.el7 cr 429 k libvirt-client x86_64=20 1.2.17-13.el7_2.2 cr 4.3 M libvirt-daemon x86_64=20 1.2.17-13.el7_2.2 cr 584 k libvirt-daemon-config-nwfilter x86_64=20 1.2.17-13.el7_2.2 cr 121 k libvirt-daemon-driver-interface x86_64=20 1.2.17-13.el7_2.2 cr 161 k libvirt-daemon-driver-network x86_64=20 1.2.17-13.el7_2.2 cr 301 k libvirt-daemon-driver-nodedev x86_64=20 1.2.17-13.el7_2.2 cr 160 k libvirt-daemon-driver-nwfilter x86_64=20 1.2.17-13.el7_2.2 cr 184 k libvirt-daemon-driver-qemu x86_64=20 1.2.17-13.el7_2.2 cr 569 k libvirt-daemon-driver-secret x86_64=20 1.2.17-13.el7_2.2 cr 154 k libvirt-daemon-driver-storage x86_64=20 1.2.17-13.el7_2.2 cr 327 k libvirt-daemon-kvm x86_64=20 1.2.17-13.el7_2.2 cr 117 k libvirt-lock-sanlock x86_64=20 1.2.17-13.el7_2.2 cr 166 k libvirt-python x86_64=20 1.2.17-2.el7 cr 309 k Updating for dependencies: device-mapper x86_64=20 7:1.02.107-5.el7 cr 251 k device-mapper-event x86_64=20 7:1.02.107-5.el7 cr 167 k device-mapper-event-libs x86_64=20 7:1.02.107-5.el7 cr 169 k device-mapper-libs x86_64=20 7:1.02.107-5.el7 cr 304 k device-mapper-persistent-data x86_64=20 0.5.5-1.el7 cr 350 k dracut-config-rescue x86_64=20 033-360.el7_2 cr 49 k dracut-network x86_64=20 033-360.el7_2 cr 90 k kmod x86_64=20 20-5.el7 cr 114 k libgudev1 x86_64=20 219-19.el7 cr 64 k lvm2 x86_64=20 7:2.02.130-5.el7 cr 1.0 M lvm2-libs x86_64=20 7:2.02.130-5.el7 cr 872 k systemd x86_64=20 219-19.el7 cr 5.1 M systemd-libs x86_64=20 219-19.el7 cr 356 k systemd-python x86_64=20 219-19.el7 cr 97 k systemd-sysv x86_64=20 219-19.el7 cr 52 k
Transaction Summary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D 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=20 start VM. VM situation $ free total used free shared buff/cache =20 available Mem: 8172900 147356 7875692 8480 149852 78472= 48 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=20 /var/log/messages:
could it be perhaps the guest has troubles recognizing hotplug? Is it=20 also a CentOS 7.1 guest?
Dec 9 23:56:18 racclient1 kernel: init_memory_mapping: [mem=20 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 ->=20 [ffff8800b7e00000-ffff8800b7ffffff] on node 0 [ 219.368433] [ffffea0009200000-ffffea00093fffff] PMD ->=20 [ffff880231400000-ffff8802315fffff] on node 0 [ 219.369838] [ffffea0009400000-ffffea00095fffff] PMD ->=20 [ffff880233600000-ffff8802337fffff] on node 0 [ 219.371226] [ffffea0009600000-ffffea00097fffff] PMD ->=20 [ffff880233000000-ffff8802331fffff] on node 0 [ 219.372790] [ffffea0009800000-ffffea00099fffff] PMD ->=20 [ffff880232c00000-ffff880232dfffff] on node 0 [ 219.374185] [ffffea0009a00000-ffffea0009bfffff] PMD ->=20 [ffff880232200000-ffff8802323fffff] on node 0 [ 219.377349] [ffffea0009c00000-ffffea0009ffffff] PMD ->=20 [ffff8800b7400000-ffff8800b77fffff] on node 0 [ 219.378716] [ffffea000a000000-ffffea000a1fffff] PMD ->=20 [ffff8800b7000000-ffff8800b71fffff] on node 0 [ 219.380115] [ffffea000a200000-ffffea000a3fffff] PMD ->=20 [ffff880230c00000-ffff880230dfffff] on node 0 [ 219.388147] [ffffea000a400000-ffffea000abfffff] PMD ->=20 [ffff880227c00000-ffff8802283fffff] on node 0 [ 219.389687] [ffffea000ac00000-ffffea000adfffff] PMD ->=20 [ffff8800b7200000-ffff8800b73fffff] on node 0
but =93free=94 sstill shows the same value as before hotplug?
I then shutdown the VM and power on it again and I get the changed=20 memory:
well, yeah, but that doesn=92t count since you=92ve shut it down, so th= e=20 next run is initialized with 10GB
$ free total used free shared buff/cache =20 available Mem: 10237276 167872 9919656 8480 149748 98912= 80 Swap: 839676 0 839676
BTW: When I press ok in the gui for memory increase I get these=20 events in webadmin: Dec 9, 2015 11:56:22 PM VM racclient1 c71_Disk1_newtemplate disk was updated by admin@internal= .
hm..doesn=92t sound right. Did the confirmation window show any more=20 fields as changed other than memory?
Dec 9, 2015 11:56:19 PM VM racclient1 configuration was updated by admin@internal.
that=92s 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=20 8192 to 10240
that=92s the actual hotplug
It doesn't seem as expected, does it?
I think we=92re almost there. Just need to figure out what happened in=20 the guest. I would suspect a problem there I did the same test, I obtain the same result but here is what I get=20 into the /var/log/messages guest (7.1) logs and not mentionned there: unsupported configuration: maxMemory has to be specified when using=20 memory devices What can't I do with this error, is it a known issue?
Thanks, michal
Gianluca
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
gianluca.cecchi@gmail.com</a></a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote">On Wed, Dec 9, 2015 at 10:21 PM, Sandro Bonazzola=A0<span dir=3D"ltr" class=3D""></s=
--=20 Nathana=EBl Blanchet Supervision r=E9seau P=F4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=E9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet@abes.fr --------------080701070002030103070807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> <br> <div class=3D"moz-cite-prefix">Le 10/12/2015 10:41, Michal Skrivanek = a =E9crit=A0:<br> </div> <blockquote cite=3D"mid:F8823B97-23FD-4125-B374-EE3918F3A383@redhat.com" type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-1252"> <br class=3D""> <div> <blockquote type=3D"cite" class=3D""> <div class=3D"">On 10 Dec 2015, at 00:11, Gianluca Cecchi <<= a moz-do-not-send=3D"true" href=3D"mailto:gianluca.cecchi@gmail.com" class=3D""><a cla= ss=3D"moz-txt-link-abbreviated" href=3D"mailto:gianluca.cecchi@gmail.com"= pan> wrote:<br class=3D""> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir=3D"ltr" class=3D""><br class=3D""> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"><span class=3D""> <div class=3D""><br class=3D""> </div> </span> <div class=3D"">No idea. If it's libvirt issue, can you test=A0<a moz-do-not-send=3D"true" href=3D"http://cbs.centos.org/koji/buildinf= o?buildID=3D4726" target=3D"_blank" class=3D"">http://cbs.cen= tos.org/koji/buildinfo?buildID=3D4726</a> ? it's from centos virt sig, introduced for Xen but should work on kvm as well. or the 7.2 libvirt from=A0<a moz-do-not-send=3D"true= " href=3D"http://mirror.centos.org/centos/7/c= r/x86_64/Packages/" target=3D"_blank" class=3D"">http://mirror.= centos.org/centos/7/cr/x86_64/Packages/</a>.</div> <div class=3D""> <div class=3D"h5"> <div class=3D""><br class=3D""> </div> <div class=3D""><br class=3D""> </div> </div> </div> </div> </div> </div> </blockquote> </div> <br class=3D""> Hello,<br class=3D""> tried on a test environment where I have 3.6.0 on single CentOS 7.1 hypervisor configured with SelfHostedEngine<br class=3D""> I have a CentOS 7.1 vm running.<br class=3D""> <br class=3D""> On hypervisor I shutdown VM, put maintenance global and shutdown engine VM.<br class=3D""> Then<br class=3D""> [root@ractor ~]# yum --enablerepo=3Dcr update libvirt*<br class=3D""> Loaded plugins: fastestmirror, langpacks<br class=3D""> cr=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 | 3.4 kB=A0 00:00:00=A0=A0=A0=A0 <br class=3D""> cr/7/x86_64/primary_db=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 3.7 MB=A0 00:00:02=A0=A0=A0=A0 <br class=3D""> Loading mirror speeds from cached hostfile<br class=3D""> =A0* base: <a moz-do-not-send=3D"true" href=3D"http://centos.fastbull.org/" class=3D"">centos.= fastbull.org</a><br class=3D""> =A0* extras: <a moz-do-not-send=3D"true" href=3D"http://centos.fastbull.org/" class=3D"">centos.= fastbull.org</a><br class=3D""> =A0* ovirt-3.6: <a moz-do-not-send=3D"true" href=3D"http://ftp.nluug.nl/" class=3D"">ftp.nluug.nl</= a><br class=3D""> =A0* ovirt-3.6-epel: <a moz-do-not-send=3D"true" href=3D"http://epel.besthosting.ua/" class=3D"">epel.be= sthosting.ua</a><br class=3D""> =A0* updates: <a moz-do-not-send=3D"true" href=3D"http://centos.copahost.com/" class=3D"">centos.= copahost.com</a><br class=3D""> Resolving Dependencies<br class=3D""> --> Running transaction check<br class=3D""> ---> Package libvirt-client.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-client.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> --> Processing Dependency: libsystemd.so.0(LIBSYSTEMD_209)(64bit) for package: libvirt-client-1.2.17-13.el7_2.2.x86_64<br class=3D""> --> Processing Dependency: libsystemd.so.0()(64bit) for package: libvirt-client-1.2.17-13.el7_2.2.x86_64<br class=3D""> ---> Package libvirt-daemon.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-config-nwfilter.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-config-nwfilter.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-interface.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-interface.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-network.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-network.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-secret.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-driver-storage.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> --> 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<br class=3D""> ---> Package libvirt-daemon-kvm.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-daemon-kvm.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-lock-sanlock.x86_64 0:1.2.8-16.el7_1.5 will be updated<br class=3D""> ---> Package libvirt-lock-sanlock.x86_64 0:1.2.17-13.el7_2.2 will be an update<br class=3D""> ---> Package libvirt-python.x86_64 0:1.2.8-7.el7_1.1 will be updated<br class=3D""> ---> Package libvirt-python.x86_64 0:1.2.17-2.el7 will be an update<br class=3D""> --> Running transaction check<br class=3D""> ---> Package device-mapper-libs.x86_64 7:1.02.93-3.el7_1.1 will be updated<br class=3D""> --> Processing Dependency: device-mapper-libs =3D 7:1.02.93-3.el7_1.1 for package: 7:device-mapper-1.02.93-3.el7_1.1.x86_64<br class=3D""> ---> Package device-mapper-libs.x86_64 7:1.02.107-5.el7 will be an update<br class=3D""> ---> Package systemd-libs.x86_64 0:208-20.el7_1.6 will be updated<br class=3D""> --> Processing Dependency: systemd-libs =3D 208-20.el7_1.6 for package: systemd-208-20.el7_1.6.x86_64<br class=3D""> ---> Package systemd-libs.x86_64 0:219-19.el7 will be an update<br class=3D""> --> Running transaction check<br class=3D""> ---> Package device-mapper.x86_64 7:1.02.93-3.el7_1.1 will be updated<br class=3D""> --> Processing Dependency: device-mapper =3D 7:1.02.93-3.el7_1.1 for package: 7:device-mapper-event-1.02.93-3.el7_1.1.x86_64<br class=3D""> ---> Package device-mapper.x86_64 7:1.02.107-5.el7 will be an update<br class=3D""> ---> Package systemd.x86_64 0:208-20.el7_1.6 will be updated<br class=3D""> --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package: systemd-sysv-208-20.el7_1.6.x86_64<br class=3D""> --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package: systemd-python-208-20.el7_1.6.x86_64<br class=3D""> --> Processing Dependency: systemd =3D 208-20.el7_1.6 for package: libgudev1-208-20.el7_1.6.x86_64<br class=3D"= "> ---> Package systemd.x86_64 0:219-19.el7 will be an update<br class=3D""> --> Processing Dependency: kmod >=3D 18-4 for package: systemd-219-19.el7.x86_64<br class=3D""> --> Running transaction check<br class=3D""> ---> Package device-mapper-event.x86_64 7:1.02.93-3.el7_1.1 will be updated<br class=3D""> --> Processing Dependency: device-mapper-event =3D 7:1.02.93-3.el7_1.1 for package: 7:lvm2-libs-2.02.115-3.el7_1.1.x86_64<br class=3D""> ---> Package device-mapper-event.x86_64 7:1.02.107-5.el7 will be an update<br class=3D""> --> Processing Dependency: device-mapper-event-libs =3D 7:1.02.107-5.el7 for package: 7:device-mapper-event-1.02.107-5.el7.x86_64<br class=3D""=
---> Package kmod.x86_64 0:14-10.el7 will be updated<b= r class=3D""> ---> Package kmod.x86_64 0:20-5.el7 will be an update<= br class=3D""> ---> Package libgudev1.x86_64 0:208-20.el7_1.6 will be updated<br class=3D""> ---> Package libgudev1.x86_64 0:219-19.el7 will be an update<br class=3D""> ---> Package systemd-python.x86_64 0:208-20.el7_1.6 will be updated<br class=3D""> ---> Package systemd-python.x86_64 0:219-19.el7 will be an update<br class=3D""> ---> Package systemd-sysv.x86_64 0:208-20.el7_1.6 will be updated<br class=3D""> ---> Package systemd-sysv.x86_64 0:219-19.el7 will be an update<br class=3D""> --> Running transaction check<br class=3D""> ---> Package device-mapper-event-libs.x86_64 7:1.02.93-3.el7_1.1 will be updated<br class=3D""> ---> Package device-mapper-event-libs.x86_64 7:1.02.107-5.el7 will be an update<br class=3D""> ---> Package lvm2-libs.x86_64 7:2.02.115-3.el7_1.1 will be updated<br class=3D""> --> Processing Dependency: lvm2-libs =3D 7:2.02.115-3.el7_1.1 for package: 7:lvm2-2.02.115-3.el7_1.1.x86_64<br class=3D""> ---> Package lvm2-libs.x86_64 7:2.02.130-5.el7 will be an update<br class=3D""> --> Running transaction check<br class=3D""> ---> Package lvm2.x86_64 7:2.02.115-3.el7_1.1 will be updated<br class=3D""> ---> Package lvm2.x86_64 7:2.02.130-5.el7 will be an update<br class=3D""> --> Processing Dependency: device-mapper-persistent-data >=3D 0.5.5-1 for package= : 7:lvm2-2.02.130-5.el7.x86_64<br class=3D""> --> Running transaction check<br class=3D""> ---> Package device-mapper-persistent-data.x86_64 0:0.4.1-2.el7 will be updated<br class=3D""> ---> Package device-mapper-persistent-data.x86_64 0:0.5.5-1.el7 will be an update<br class=3D""> --> Processing Conflict: systemd-219-19.el7.x86_64 conflicts initscripts < 9.49.28-1<br class=3D""> --> Restarting Dependency Resolution with new changes.<br class=3D""> --> Running transaction check<br class=3D""> ---> Package initscripts.x86_64 0:9.49.24-1.el7 will be updated<br class=3D""> ---> Package initscripts.x86_64 0:9.49.30-1.el7 will be an update<br class=3D""> --> Processing Conflict: systemd-219-19.el7.x86_64 conflicts dracut < 033-243<br class=3D""> --> Restarting Dependency Resolution with new changes.<br class=3D""> --> Running transaction check<br class=3D""> ---> Package dracut.x86_64 0:033-241.el7_1.5 will be updated<br class=3D""> --> Processing Dependency: dracut =3D 033-241.el7_1.5 for package: dracut-config-rescue-033-241.el7_1.5.x86_64<= br class=3D""> --> Processing Dependency: dracut =3D 033-241.el7_1.5 for package: dracut-network-033-241.el7_1.5.x86_64<br class=3D""> ---> Package dracut.x86_64 0:033-360.el7_2 will be an update<br class=3D""> --> Running transaction check<br class=3D""> ---> Package dracut-config-rescue.x86_64 0:033-241.el7_1.5 will be updated<br class=3D""> ---> Package dracut-config-rescue.x86_64 0:033-360.el7_2 will be an update<br class=3D""> ---> Package dracut-network.x86_64 0:033-241.el7_1.5 will be updated<br class=3D""> ---> Package dracut-network.x86_64 0:033-360.el7_2 will be an update<br class=3D""> --> Finished Dependency Resolution<br class=3D""> <br class=3D""> Dependencies Resolved<br class=3D""> <br class=3D""> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <br class=3D""> =A0Package=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Arch=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Version=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Repository=A0 Size<br class=3D""> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <br class=3D""> Updating:<br class=3D""> =A0dracut=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0= =A0=A0=A0 033-360.el7_2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0= =A0=A0=A0=A0=A0=A0=A0 311 k<br class=3D""> =A0initscripts=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 9.49.30-1.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0= =A0=A0=A0=A0=A0=A0=A0 429 k<br class=3D""> =A0libvirt-client=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 4.3 M<br class=3D""> =A0libvirt-daemon=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 584 k<br class=3D""> =A0libvirt-daemon-config-nwfilter=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 121 k<br class=3D""> =A0libvirt-daemon-driver-interface=A0=A0=A0=A0=A0=A0=A0=A0= x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 161 k<br class=3D""> =A0libvirt-daemon-driver-network=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 301 k<br class=3D""> =A0libvirt-daemon-driver-nodedev=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 160 k<br class=3D""> =A0libvirt-daemon-driver-nwfilter=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 184 k<br class=3D""> =A0libvirt-daemon-driver-qemu=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 569 k<br class=3D""> =A0libvirt-daemon-driver-secret=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 154 k<br class=3D""> =A0libvirt-daemon-driver-storage=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 327 k<br class=3D""> =A0libvirt-daemon-kvm=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 117 k<br class=3D""> =A0libvirt-lock-sanlock=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-13.el7_2.2=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0=A0= =A0=A0=A0=A0 166 k<br class=3D""> =A0libvirt-python=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 1.2.17-2.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr= =A0=A0=A0=A0=A0=A0=A0=A0 309 k<br class=3D""> Updating for dependencies:<br class=3D""> =A0device-mapper=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 7:1.02.107-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 251 k<br class=3D""> =A0device-mapper-event=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 7:1.02.107-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 167 k<br class=3D""> =A0device-mapper-event-libs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 7:1.02.107-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 169 k<br class=3D""> =A0device-mapper-libs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 7:1.02.107-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 304 k<br class=3D""> =A0device-mapper-persistent-data=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 0.5.5-1.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = cr=A0=A0=A0=A0=A0=A0=A0=A0 350 k<br class=3D""> =A0dracut-config-rescue=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 033-360.el7_2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0= =A0=A0=A0=A0=A0=A0=A0=A0 49 k<br class=3D""> =A0dracut-network=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 033-360.el7_2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0= =A0=A0=A0=A0=A0=A0=A0=A0 90 k<br class=3D""> =A0kmod=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0= =A0=A0=A0=A0 20-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 cr=A0=A0=A0=A0=A0=A0=A0=A0 114 k<br class=3D""> =A0libgudev1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0= =A0 219-19.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= cr=A0=A0=A0=A0=A0=A0=A0=A0=A0 64 k<br class=3D""> =A0lvm2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0= =A0=A0=A0=A0 7:2.02.130-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 1.0 M<br class=3D""> =A0lvm2-libs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0= =A0 7:2.02.130-5.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cr=A0=A0=A0= =A0=A0=A0=A0=A0 872 k<br class=3D""> =A0systemd=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0= =A0=A0 219-19.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= cr=A0=A0=A0=A0=A0=A0=A0=A0 5.1 M<br class=3D""> =A0systemd-libs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 219-19.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= cr=A0=A0=A0=A0=A0=A0=A0=A0 356 k<br class=3D""> =A0systemd-python=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 219-19.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= cr=A0=A0=A0=A0=A0=A0=A0=A0=A0 97 k<br class=3D""> =A0systemd-sysv=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x86_64=A0=A0=A0=A0=A0=A0=A0=A0 219-19.el7=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= cr=A0=A0=A0=A0=A0=A0=A0=A0=A0 52 k<br class=3D""> <br class=3D""> Transaction Summary<br class=3D""> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= <br class=3D""> Upgrade=A0 15 Packages (+15 Dependent packages)<br class=3D""> <br class=3D""> Total download size: 17 M<br class=3D""> Is this ok [y/d/N]: <br class=3D""> <br class=3D""> Then I reboot my HV, exit from maintenance, connect to engine and start VM.<br class=3D""> VM situation<br class=3D""> $ free<br class=3D""> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 total=A0=A0=A0=A0= =A0=A0=A0 used=A0=A0=A0=A0=A0=A0=A0 free=A0=A0=A0=A0=A0 shared=A0 buff/cache=A0=A0 available<br class=3D""> Mem:=A0=A0=A0=A0=A0=A0=A0 8172900=A0=A0=A0=A0=A0 147356=A0= =A0=A0=A0 7875692=A0=A0=A0=A0=A0=A0=A0 8480=A0=A0=A0=A0=A0 149852=A0=A0=A0=A0 7847248<br class=3D= ""> Swap:=A0=A0=A0=A0=A0=A0=A0 839676=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0 839676<br class=3D""> <br class=3D""> </div> <div class=3D"gmail_extra">I set memory from 8192Mb to 10240Mb<br class=3D""> </div> <div class=3D"gmail_extra">I get the same window I got with previous libvirt version.<br class=3D""> </div> <div class=3D"gmail_extra">I select OK (I don't select "Apply later" checkbox)<br class=3D""> </div> <div class=3D"gmail_extra"><br class=3D""> </div> <div class=3D"gmail_extra">Inside guest there is no changed memory, but I can see this in /var/log/messages:<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> could it be perhaps the guest has troubles recognizing hotplug? Is it also a CentOS 7.1 guest?</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"><br class=3D""> Dec=A0 9 23:56:18 racclient1 kernel: init_memory_mapping: [mem 0x240000000-0x2bfffffff]<br class=3D""> <br class=3D""> </div> <div class=3D"gmail_extra">ANd output of dmesg contains:<br class=3D""> </div> <div class=3D"gmail_extra"><br class=3D""> [=A0 219.363640] ACPI: \_SB_.MP00: ACPI_NOTIFY_DEVICE_CHECK event<br class=3D""> [=A0 219.364248] init_memory_mapping: [mem 0x240000000-0x2bfffffff]<br class=3D""> [=A0 219.364253]=A0 [mem 0x240000000-0x2bfffffff] page 2M= <br class=3D""> [=A0 219.366773]=A0 [ffffea0009000000-ffffea00091fffff] P= MD -> [ffff8800b7e00000-ffff8800b7ffffff] on node 0<br class=3D""> [=A0 219.368433]=A0 [ffffea0009200000-ffffea00093fffff] P= MD -> [ffff880231400000-ffff8802315fffff] on node 0<br class=3D""> [=A0 219.369838]=A0 [ffffea0009400000-ffffea00095fffff] P= MD -> [ffff880233600000-ffff8802337fffff] on node 0<br class=3D""> [=A0 219.371226]=A0 [ffffea0009600000-ffffea00097fffff] P= MD -> [ffff880233000000-ffff8802331fffff] on node 0<br class=3D""> [=A0 219.372790]=A0 [ffffea0009800000-ffffea00099fffff] P= MD -> [ffff880232c00000-ffff880232dfffff] on node 0<br class=3D""> [=A0 219.374185]=A0 [ffffea0009a00000-ffffea0009bfffff] P= MD -> [ffff880232200000-ffff8802323fffff] on node 0<br class=3D""> [=A0 219.377349]=A0 [ffffea0009c00000-ffffea0009ffffff] P= MD -> [ffff8800b7400000-ffff8800b77fffff] on node 0<br class=3D""> [=A0 219.378716]=A0 [ffffea000a000000-ffffea000a1fffff] P= MD -> [ffff8800b7000000-ffff8800b71fffff] on node 0<br class=3D""> [=A0 219.380115]=A0 [ffffea000a200000-ffffea000a3fffff] P= MD -> [ffff880230c00000-ffff880230dfffff] on node 0<br class=3D""> [=A0 219.388147]=A0 [ffffea000a400000-ffffea000abfffff] P= MD -> [ffff880227c00000-ffff8802283fffff] on node 0<br class=3D""> [=A0 219.389687]=A0 [ffffea000ac00000-ffffea000adfffff] P= MD -> [ffff8800b7200000-ffff8800b73fffff] on node 0<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> but =93free=94 sstill shows the same value as before hotplug?</di= v> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"><br class=3D""> I then shutdown the VM and power on it again and I get the changed memory:<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> well, yeah, but that doesn=92t count since you=92ve shut it down,= so the next run is initialized with 10GB</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra">$ free<br class=3D""> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 total=A0=A0=A0=A0= =A0=A0=A0 used=A0=A0=A0=A0=A0=A0=A0 free=A0=A0=A0=A0=A0 shared=A0 buff/cache=A0=A0 available<br class=3D""> Mem:=A0=A0=A0=A0=A0=A0 10237276=A0=A0=A0=A0=A0 167872=A0=A0= =A0=A0 9919656=A0=A0=A0=A0=A0=A0=A0 8480=A0=A0=A0=A0=A0 149748=A0=A0=A0=A0 9891280<br class=3D= ""> Swap:=A0=A0=A0=A0=A0=A0=A0 839676=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0 839676<br class=3D""> <br class=3D""> </div> <div class=3D"gmail_extra">BTW: When I press ok in the gui for memory increase I get these events in webadmin:<br class=3D""> Dec 9, 2015 11:56:22 PM<br class=3D""> VM racclient1 c71_Disk1_newtemplate disk was updated by admin@internal.<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> hm..doesn=92t sound right. Did the confirmation window show any more fields as changed other than memory?</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra">=A0=A0=A0 <br class=3D""> Dec 9, 2015 11:56:19 PM<br class=3D""> VM racclient1 configuration was updated by admin@internal.<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> that=92s correct - the new base for the next run</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra">=A0=A0=A0 <br class=3D""> Dec 9, 2015 11:56:18 PM=A0 <br class=3D""> Hotset memory: changed the amount of memory on VM racclient1 from 8192 to 10240<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> that=92s the actual hotplug</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra"><br class=3D""> </div> <div class=3D"gmail_extra">It doesn't seem as expected, doe= s it?<br class=3D""> </div> </div> </div> </blockquote> <div><br class=3D""> </div> I think we=92re almost there. Just need to figure out what happened in the guest. I would suspect a problem there</div> </blockquote> 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:<br> unsupported configuration: maxMemory has to be specified when using memory devices<br> What can't I do with this error, is it a known issue?<br> <blockquote cite=3D"mid:F8823B97-23FD-4125-B374-EE3918F3A383@redhat.com" type=3D"cite"> <div><br class=3D""> </div> <div>Thanks,</div> <div>michal</div> <div><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div dir=3D"ltr" class=3D""> <div class=3D"gmail_extra">Gianluca<br class=3D""> </div> <div class=3D"gmail_extra"><br class=3D""> </div> </div> </div> </blockquote> </div> <br class=3D""> <br> <fieldset class=3D"mimeAttachmentHeader"></fieldset> <br> <pre wrap=3D"">_______________________________________________ Users mailing list <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Users@ovirt.org">Use= rs@ovirt.org</a> <a class=3D"moz-txt-link-freetext" href=3D"http://lists.ovirt.org/mailman= /listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=EBl Blanchet Supervision r=E9seau P=F4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=E9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet@abes.fr</a> </pre> </body> </html> --------------080701070002030103070807--

On Thu, Dec 10, 2015 at 11:31 AM, Nathanaël Blanchet <blanchet@abes.fr> wrote:
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?
In my case I only got the line I wrote in previous e-mail when I click ok in web gui to increase memory: Dec 9 23:56:18 racclient1 kernel: init_memory_mapping: [mem 0x240000000-0x2bfffffff] See here the messages boot related lines for my guest, just before I tried to increase memory, in case they can be useful: https://drive.google.com/file/d/0BwoPbcrMv8mvNnFmUDMybXpla1E/view?usp=sharin... BTW: Nathanaël did you increase by 256Mb multiples? I see this is a sort of limitation... what was previous amount of ram of VM and the tried new setting?
participants (5)
-
Gianluca Cecchi
-
Michal Skrivanek
-
Nathanaël Blanchet
-
Sandro Bonazzola
-
Yaniv Dary