2:03 a.m.
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
12:19 p.m.
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(a)redhat.com
IRC : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathanaël Blanchet <blanchet(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:43 p.m.
--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--
3:54 p.m.
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(a)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(a)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(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users(a)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(a)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(a)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(a)abes.fr</a></a>&gt;</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"=
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"
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(a)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(a)abes.fr</a> </pre>
</body>
</html>
--------------010609060205050302070908--
6:12 p.m.
--Apple-Mail=_8A47B8CA-BC31-4809-A2A5-98B564DFE94F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 09 Dec 2015, at 14:54, Nathana=C3=ABl Blanchet
<blanchet(a)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(a)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/Fea...
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 =
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(a)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(a)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(a)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(a)abes.fr</a>&gt; =
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(a)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:...
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(a)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<... =
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(a)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<...
=
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--
6:54 p.m.
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(a)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(a)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(a)redhat.com=20
>>> <mailto:ydary@redhat.com> IRC : ydary
>>>
>>> On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet=20
>>> <blanchet(a)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=
ml,
>>> 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?
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(a)ovirt.org <mailto:Users@ovirt.org>
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)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(a)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(a)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(a)abes.fr</a>&gt;
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(a)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_Pl...
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(a)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(a)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(a)abes.fr</a> </pre>
</body>
</html>
--------------080201090102080009050406--
7 p.m.
--Apple-Mail=_9E193F6D-8986-4D9D-9C11-5DD9F6C4E0C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 09 Dec 2015, at 17:54, Nathana=C3=ABl Blanchet
<blanchet(a)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(a)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(a)redhat.com <mailto:ydary@redhat.com>
>>>> IRC : ydary
>>>>=20
>>>> On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet =
<blanchet(a)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/Fea...
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 =
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(a)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(a)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(a)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(a)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(a)abes.fr</a>&gt; =
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(a)abes.fr</a>&gt; =
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(a)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"></... =
class=3D"moz-txt-link-freetext" =
href=3D"http://www.ovirt.org/Features/Hot_Plug_Memory">http:...
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(a)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<... =
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(a)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<...
=
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--
7:07 p.m.
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(a)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(a)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(a)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(a)redhat.com=20
>>>>> <mailto:ydary@redhat.com> IRC : ydary
>>>>>
>>>>> On Tue, Dec 8, 2015 at 2:03 AM, Nathana=C3=ABl Blanchet=20
>>>>> <blanchet(a)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=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)
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(a)ovirt.org <mailto:Users@ovirt.org>
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users(a)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(a)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(a)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(a)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(a)abes.fr</a>&gt;
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(a)abes.fr</a>&gt;
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(a)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(a)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">=
<a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:blanchet@abes.fr">bl=
anchet(a)abes.fr</a></a>&gt;</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_Memo...;,
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"_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(a)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(a)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=
<br
class=3D"">
<span class=3D""><a
moz-do-not-send=3D"tr=
ue"
href=3D"mailto:Users@ovirt.org"
class=3D"">Users(a)ovirt.org</a></span>=
<br
class=3D"">
<span class=3D""><a
moz-do-not-send=3D"tr=
ue"
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(a)abes.fr</a> </pre>
</body>
</html>
--------------000509010800090403090309--
9:04 p.m.
--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--
10:47 p.m.
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=sha...
Gianluca
11:21 p.m.
On Wed, Dec 9, 2015 at 8:04 PM, Michal Skrivanek <mskrivan(a)redhat.com>
wrote:
On 09 Dec 2015, at 18:07, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
Le 09/12/2015 18:00, Michal Skrivanek a écrit :
On 09 Dec 2015, at 17:54, Nathanaël Blanchet <blanchet(a)abes.fr> wrote:
Le 09/12/2015 17:12, Michal Skrivanek a écrit :
On 09 Dec 2015, at 14:54, Nathanaël Blanchet <blanchet(a)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(a)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(a)redhat.com
IRC : ydary
On Tue, Dec 8, 2015 at 2:03 AM, Nathanaël Blanchet < <blanchet(a)abes.fr>
blanchet(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)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(a)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(a)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(a)abes.fr
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
1:11 a.m.
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
11:41 a.m.
--Apple-Mail=_D07768CA-8F60-41D9-9659-347CA26627F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 10 Dec 2015, at 00:11, Gianluca Cecchi
<gianluca.cecchi(a)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 =
libvirt from http://mirror.centos.org/centos/7/cr/x86_64/Packages/ =
<http://mirror.centos.org/centos/7/cr/x86_64/Packages/>;.
=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 =
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 =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-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 =
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: =
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:
=
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: =
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 =
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
--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(a)gmail.com</a>&gt;
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=3D47... ? =
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/Packa...
<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 =
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(a)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(a)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--
12:30 p.m.
On Thu, Dec 10, 2015 at 10:41 AM, Michal Skrivanek <mskrivan(a)redhat.com>
wrote:
On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi(a)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=sha...
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
1:24 p.m.
On 10 Dec 2015, at 11:30, Gianluca Cecchi
<gianluca.cecchi(a)gmail.com> wrote:
On Thu, Dec 10, 2015 at 10:41 AM, Michal Skrivanek <mskrivan(a)redhat.com> wrote:
> On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi(a)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=sha...
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
2:16 p.m.
On Thu, Dec 10, 2015 at 12:24 PM, Michal Skrivanek <mskrivan(a)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
3:35 p.m.
--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(a)gmail.com> =
wrote:
=20
On Thu, Dec 10, 2015 at 12:24 PM, Michal Skrivanek =
<mskrivan(a)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(a)gmail.com</a>&gt;
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(a)redhat.com</a>&gt;</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--
4:12 p.m.
On Thu, Dec 10, 2015 at 2:35 PM, Michal Skrivanek <mskrivan(a)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
4:34 p.m.
--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(a)gmail.com> =
wrote:
=20
On Thu, Dec 10, 2015 at 2:35 PM, Michal Skrivanek <mskrivan(a)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(a)gmail.com</a>&gt;
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(a)redhat.com</a>&gt;</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--
12:31 p.m.
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 :
<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"=
<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=
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(a)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(a)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(a)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(a)abes.fr</a> </pre </body </html
--------------080701070002030103070807--
> On 10 Dec 2015, at 00:11, Gianluca Cecchi <gianluca.cecchi(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--=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(a)abes.fr
--------------080701070002030103070807
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<htmlgianluca.cecchi(a)gmail.com</a></a>&gt;
wrote:</div
12:49 p.m.
On Thu, Dec 10, 2015 at 11:31 AM, Nathanaël Blanchet <blanchet(a)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=sha...
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?
3271
days inactive
3273
days old
21 comments
5 participants
participants (5)
-
Gianluca Cecchi -
Michal Skrivanek -
Nathanaël Blanchet -
Sandro Bonazzola -
Yaniv Dary