From midnightsteel at msn.com Tue Mar 18 10:52:06 2014 Content-Type: multipart/mixed; boundary="===============7042523165593538830==" MIME-Version: 1.0 From: Maurice James To: users at ovirt.org Subject: [Users] Processor Type Date: Tue, 18 Mar 2014 10:52:01 -0400 Message-ID: --===============7042523165593538830== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_NextPart_000_00C1_01CF4298.17B035C0 Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: 7bit How do I assign a different processor type to an individual VM? (Sandy Bridge, Conroe, etc) ------=3D_NextPart_000_00C1_01CF4298.17B035C0 Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

How do I assign a =3D different processor type to an individual VM? (Sandy Bridge, Conroe, =3D etc)

------=3D_NextPart_000_00C1_01CF4298.17B035C0-- --===============7042523165593538830== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9OZXh0UGFydF8wMDBfMDBDMV8wMUNGNDI5OC4xN0IwMzVDMApDb250ZW50LVR5cGU6 IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIgpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiA3Yml0CgpIb3cgZG8gSSBhc3NpZ24gYSBkaWZmZXJlbnQgcHJvY2Vzc29yIHR5cGUgdG8gYW4g aW5kaXZpZHVhbCBWTT8gKFNhbmR5CkJyaWRnZSwgQ29ucm9lLCBldGMpCgoKLS0tLS0tPV9OZXh0 UGFydF8wMDBfMDBDMV8wMUNGNDI5OC4xN0IwMzVDMApDb250ZW50LVR5cGU6IHRleHQvaHRtbDsg Y2hhcnNldD0idXMtYXNjaWkiCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmlu dGFibGUKCjxodG1sIHhtbG5zOnY9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiID0K eG1sbnM6bz0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiID0KeG1s bnM6dz0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiA9CnhtbG5zOm09 M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiA9Cnht bG5zPTNEImh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxoZWFkPjxNRVRBID0KSFRU UC1FUVVJVj0zRCJDb250ZW50LVR5cGUiIENPTlRFTlQ9M0QidGV4dC9odG1sOyA9CmNoYXJzZXQ9 M0R1cy1hc2NpaSI+PG1ldGEgbmFtZT0zREdlbmVyYXRvciBjb250ZW50PTNEIk1pY3Jvc29mdCBX b3JkIDE1ID0KKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOwoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxpYnJpOwoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLwpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBpbjsKCW1h cmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMS4wcHQ7Cglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsKCWNvbG9yOiMwNTYzQzE7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5OwoJY29sb3I6Izk1NEY3MjsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQpzcGFu LkVtYWlsU3R5bGUxNwoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7Cglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29sb3I6d2luZG93dGV4dDt9Ci5Nc29DaHBE ZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo4LjVpbiAxMS4waW47 CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PTNEImVkaXQiIHNwaWRtYXg9M0QiMTAyNiIgLz4KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PTNE ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0zRCJlZGl0IiBkYXRhPTNEIjEiIC8+CjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz0zREVOLVVTID0KbGluaz0z RCIjMDU2M0MxIiB2bGluaz0zRCIjOTU0RjcyIj48ZGl2IGNsYXNzPTNEV29yZFNlY3Rpb24xPjxw ID0KY2xhc3M9M0RNc29Ob3JtYWwgc3R5bGU9M0QnbWFyZ2luLXRvcDoxMi4wcHQnPkhvdyBkbyBJ IGFzc2lnbiBhID0KZGlmZmVyZW50IHByb2Nlc3NvciB0eXBlIHRvIGFuIGluZGl2aWR1YWwgVk0/ IChTYW5keSBCcmlkZ2UsIENvbnJvZSwgPQpldGMpPG86cD48L286cD48L3A+PC9kaXY+PC9ib2R5 PjwvaHRtbD4KLS0tLS0tPV9OZXh0UGFydF8wMDBfMDBDMV8wMUNGNDI5OC4xN0IwMzVDMC0tCg== --===============7042523165593538830==-- From ofrenkel at redhat.com Wed Mar 19 10:13:30 2014 Content-Type: multipart/mixed; boundary="===============7427882010521792163==" MIME-Version: 1.0 From: Omer Frenkel To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Wed, 19 Mar 2014 10:13:28 -0400 Message-ID: <452008888.2082451.1395238408758.JavaMail.zimbra@redhat.com> In-Reply-To: BLU405-EAS935111C8C65C07B62C6E10B27C0@phx.gbl --===============7427882010521792163== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ------=3D_Part_2082450_785959655.1395238408757 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Maurice James" > To: users(a)ovirt.org > Sent: Tuesday, March 18, 2014 4:52:01 PM > Subject: [Users] Processor Type > How do I assign a different processor type to an individual VM? (Sandy > Bridge, Conroe, etc) cpu name is cluster level, and usually the lowest common denominator of the= hosts in cluster, = to make sure migration works in the cluster. = so you can change for cluster, which will affect all vms in the cluster, no= t individual vm = > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users ------=3D_Part_2082450_785959655.1395238408757 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: 7bit


Fr= om: "Maurice James" <midnightsteel(a)msn.com>
To: users= (a)ovirt.org
Sent: Tuesday, March 18, 2014 4:52:01 PM
Subje= ct: [Users] Processor Type

How do I assign a different processor type to an individual = VM? (Sandy Bridge, Conroe, etc)

cpu name is clus= ter level, and usually the lowest common denominator of the hosts in cluste= r,
to make sure migration works in the cluster.

so you can change for cluster, which will affect all vms in= the cluster, not individual vm
_______________________________________________Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/= listinfo/users

------=3D_Part_2082450_785959655.1395238408757-- --===============7427882010521792163== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIwODI0NTBfNzg1OTU5NjU1LjEzOTUyMzg0MDg3NTcKQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PXV0Zi04CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdi aXQKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KCj4gRnJvbTogIk1hdXJpY2UgSmFtZXMi IDxtaWRuaWdodHN0ZWVsQG1zbi5jb20+Cj4gVG86IHVzZXJzQG92aXJ0Lm9yZwo+IFNlbnQ6IFR1 ZXNkYXksIE1hcmNoIDE4LCAyMDE0IDQ6NTI6MDEgUE0KPiBTdWJqZWN0OiBbVXNlcnNdIFByb2Nl c3NvciBUeXBlCgo+IEhvdyBkbyBJIGFzc2lnbiBhIGRpZmZlcmVudCBwcm9jZXNzb3IgdHlwZSB0 byBhbiBpbmRpdmlkdWFsIFZNPyAoU2FuZHkKPiBCcmlkZ2UsIENvbnJvZSwgZXRjKQoKY3B1IG5h bWUgaXMgY2x1c3RlciBsZXZlbCwgYW5kIHVzdWFsbHkgdGhlIGxvd2VzdCBjb21tb24gZGVub21p bmF0b3Igb2YgdGhlIGhvc3RzIGluIGNsdXN0ZXIsIAp0byBtYWtlIHN1cmUgbWlncmF0aW9uIHdv cmtzIGluIHRoZSBjbHVzdGVyLiAKCnNvIHlvdSBjYW4gY2hhbmdlIGZvciBjbHVzdGVyLCB3aGlj aCB3aWxsIGFmZmVjdCBhbGwgdm1zIGluIHRoZSBjbHVzdGVyLCBub3QgaW5kaXZpZHVhbCB2bSAK Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBVc2Vy cyBtYWlsaW5nIGxpc3QKPiBVc2Vyc0BvdmlydC5vcmcKPiBodHRwOi8vbGlzdHMub3ZpcnQub3Jn L21haWxtYW4vbGlzdGluZm8vdXNlcnMKCi0tLS0tLT1fUGFydF8yMDgyNDUwXzc4NTk1OTY1NS4x Mzk1MjM4NDA4NzU3CkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04CkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPjxib2R5PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxo ciBpZD0iendjaHIiPjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDoycHggc29saWQgIzEw MTBGRjttYXJnaW4tbGVmdDo1cHg7cGFkZGluZy1sZWZ0OjVweDtjb2xvcjojMDAwO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LWZh bWlseTpIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDsiPjxiPkZyb206 IDwvYj4iTWF1cmljZSBKYW1lcyIgJmx0O21pZG5pZ2h0c3RlZWxAbXNuLmNvbSZndDs8YnI+PGI+ VG86IDwvYj51c2Vyc0BvdmlydC5vcmc8YnI+PGI+U2VudDogPC9iPlR1ZXNkYXksIE1hcmNoIDE4 LCAyMDE0IDQ6NTI6MDEgUE08YnI+PGI+U3ViamVjdDogPC9iPltVc2Vyc10gUHJvY2Vzc29yIFR5 cGU8YnI+PGRpdj48YnI+PC9kaXY+PHN0eWxlPjwhLS0KCkBmb250LWZhY2UKCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1m YWNlCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30KCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGlu OwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjp3aW5kb3d0ZXh0O30KLk1z b0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjguNWluIDEx LjBpbjsKCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9CmRpdi5Xb3JkU2VjdGlvbjEK CXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXRvcDoxMi4wcHQiPkhvdyBkbyBJ IGFzc2lnbiBhIGRpZmZlcmVudCBwcm9jZXNzb3IgdHlwZSB0byBhbiBpbmRpdmlkdWFsIFZNPyAo U2FuZHkgQnJpZGdlLCBDb25yb2UsIGV0Yyk8L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+Y3B1 IG5hbWUgaXMgY2x1c3RlciBsZXZlbCwgYW5kIHVzdWFsbHkgdGhlIGxvd2VzdCBjb21tb24gZGVu b21pbmF0b3Igb2YgdGhlIGhvc3RzIGluIGNsdXN0ZXIsPGJyPjwvZGl2PjxkaXY+dG8gbWFrZSBz dXJlIG1pZ3JhdGlvbiB3b3JrcyBpbiB0aGUgY2x1c3Rlci48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5zbyB5b3UgY2FuIGNoYW5nZSBmb3IgY2x1c3Rlciwgd2hpY2ggd2lsbCBhZmZlY3Qg YWxsIHZtcyBpbiB0aGUgY2x1c3Rlciwgbm90IGluZGl2aWR1YWwgdm08YnI+PC9kaXY+PGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0OjJweCBzb2xpZCAjMTAxMEZGO21hcmdpbi1sZWZ0OjVw eDtwYWRkaW5nLWxlZnQ6NXB4O2NvbG9yOiMwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZvbnQtc3R5 bGU6bm9ybWFsO3RleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlh bCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMnB0OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+VXNlcnMgbWFpbGluZyBsaXN0PGJyPlVzZXJzQG92aXJ0 Lm9yZzxicj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+Ci0tLS0tLT1f UGFydF8yMDgyNDUwXzc4NTk1OTY1NS4xMzk1MjM4NDA4NzU3LS0K --===============7427882010521792163==-- From iheim at redhat.com Mon Mar 24 10:26:54 2014 Content-Type: multipart/mixed; boundary="===============7546040144048176733==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Mon, 24 Mar 2014 07:03:41 -0400 Message-ID: <5330110D.7030401@redhat.com> In-Reply-To: 452008888.2082451.1395238408758.JavaMail.zimbra@redhat.com --===============7546040144048176733== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/19/2014 10:13 AM, Omer Frenkel wrote: > > > ------------------------------------------------------------------------ > > *From: *"Maurice James" > *To: *users(a)ovirt.org > *Sent: *Tuesday, March 18, 2014 4:52:01 PM > *Subject: *[Users] Processor Type > > How do I assign a different processor type to an individual VM? > (Sandy Bridge, Conroe, etc) > > cpu name is cluster level, and usually the lowest common denominator of > the hosts in cluster, > to make sure migration works in the cluster. > > so you can change for cluster, which will affect all vms in the cluster, > not individual vm but if you are willing to compromise on performance, compared to live = migration in the cluster, you can choose '-cpu host' for best match of = the VM to the CPU available on the host. > > _______________________________________________ > 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 > --===============7546040144048176733==-- From rstory at tislabs.com Mon Mar 31 11:57:41 2014 Content-Type: multipart/mixed; boundary="===============7302986446729996257==" MIME-Version: 1.0 From: Robert Story To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Mon, 31 Mar 2014 11:57:35 -0400 Message-ID: <20140331115735.7847196b@ispx.vb.futz.org> In-Reply-To: 452008888.2082451.1395238408758.JavaMail.zimbra@redhat.com --===============7302986446729996257== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --Sig_/++L4I1jBnX8PskITzLvMF5_ Content-Type: text/plain; charset=3DUS-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 19 Mar 2014 10:13:28 -0400 (EDT) Omer wrote: OF> cpu name is cluster level, and usually the lowest common denominator of OF> the hosts in cluster, to make sure migration works in the cluster.=3D20 Is there and documentation on the relationship between cpu types and compatibility? Right now I have a cluster per cpu type, and it might make sense to merge some of them if the performance hit was minimal. Robert -- Senior Software Engineer @ Parsons --Sig_/++L4I1jBnX8PskITzLvMF5_ Content-Type: application/pgp-signature; name=3Dsignature.asc Content-Disposition: attachment; filename=3Dsignature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlM5kHMACgkQ7/fVLLY1mngBWACfYVXQq/kxZgWerxh51SG3783j SXQAnAwAOO3wt6YBY1bomS2g1o+Q6Ewf =3DxjyR -----END PGP SIGNATURE----- --Sig_/++L4I1jBnX8PskITzLvMF5_-- --===============7302986446729996257== Content-Type: multipart/signed MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1TaWdfLysrTDRJMWpCblg4UHNrSVR6THZNRjVfCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsg Y2hhcnNldD1VUy1BU0NJSQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRh YmxlCgpPbiBXZWQsIDE5IE1hciAyMDE0IDEwOjEzOjI4IC0wNDAwIChFRFQpIE9tZXIgd3JvdGU6 Ck9GPiBjcHUgbmFtZSBpcyBjbHVzdGVyIGxldmVsLCBhbmQgdXN1YWxseSB0aGUgbG93ZXN0IGNv bW1vbiBkZW5vbWluYXRvciBvZgpPRj4gdGhlIGhvc3RzIGluIGNsdXN0ZXIsIHRvIG1ha2Ugc3Vy ZSBtaWdyYXRpb24gd29ya3MgaW4gdGhlIGNsdXN0ZXIuPTIwCgpJcyB0aGVyZSBhbmQgZG9jdW1l bnRhdGlvbiBvbiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gY3B1IHR5cGVzIGFuZApjb21wYXRp YmlsaXR5PyBSaWdodCBub3cgSSBoYXZlIGEgY2x1c3RlciBwZXIgY3B1IHR5cGUsIGFuZCBpdCBt aWdodCBtYWtlCnNlbnNlIHRvIG1lcmdlIHNvbWUgb2YgdGhlbSBpZiB0aGUgcGVyZm9ybWFuY2Ug aGl0IHdhcyBtaW5pbWFsLgoKUm9iZXJ0CgotLQpTZW5pb3IgU29mdHdhcmUgRW5naW5lZXIgQCBQ YXJzb25zCgotLVNpZ18vKytMNEkxakJuWDhQc2tJVHpMdk1GNV8KQ29udGVudC1UeXBlOiBhcHBs aWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPXNpZ25hdHVyZS5hc2MKQ29udGVudC1EaXNwb3Np dGlvbjogYXR0YWNobWVudDsgZmlsZW5hbWU9c2lnbmF0dXJlLmFzYwoKLS0tLS1CRUdJTiBQR1Ag U0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIuMC4yMiAoR05VL0xpbnV4KQoKaUVZRUFS RUNBQVlGQWxNNWtITUFDZ2tRNy9mVkxMWTFtbmdCV0FDZllWWFFxL2t4WmdXZXJ4aDUxU0czNzgz agpTWFFBbkF3QU9PM3d0NllCWTFib21TMmcxbytRNkV3Zgo9eGp5UgotLS0tLUVORCBQR1AgU0lH TkFUVVJFLS0tLS0KCi0tU2lnXy8rK0w0STFqQm5YOFBza0lUekx2TUY1Xy0tCg== --===============7302986446729996257==-- From iheim at redhat.com Fri Apr 4 11:32:12 2014 Content-Type: multipart/mixed; boundary="===============8005657435326033953==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Fri, 04 Apr 2014 18:32:10 +0300 Message-ID: <533ED07A.2020809@redhat.com> In-Reply-To: 20140331115735.7847196b@ispx.vb.futz.org --===============8005657435326033953== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/31/2014 06:57 PM, Robert Story wrote: > On Wed, 19 Mar 2014 10:13:28 -0400 (EDT) Omer wrote: > OF> cpu name is cluster level, and usually the lowest common denominator = of > OF> the hosts in cluster, to make sure migration works in the cluster. > > Is there and documentation on the relationship between cpu types and > compatibility? Right now I have a cluster per cpu type, and it might make > sense to merge some of them if the performance hit was minimal. that would be a question for qemu-kvm - they provide the cpu models we = base this on. you can check which cpu flags you get exposed in the guest of the higher = cpu model, then check if you think your applications would care about = them... --===============8005657435326033953==-- From S.Kieske at mittwald.de Sat Apr 5 07:34:28 2014 Content-Type: multipart/mixed; boundary="===============5138145375998606182==" MIME-Version: 1.0 From: Sven Kieske To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Sat, 05 Apr 2014 11:33:15 +0000 Message-ID: <533FEA40.9040905@mittwald.de> In-Reply-To: 533ED07A.2020809@redhat.com --===============5138145375998606182== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable The cpu model actually gets read from a libvirt xml file. Extensive documentation about this can be found here: http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_differe= nt_model_from_the_hardware_documentation HTH Am 04.04.2014 17:32, schrieb Itamar Heim: > On 03/31/2014 06:57 PM, Robert Story wrote: >> On Wed, 19 Mar 2014 10:13:28 -0400 (EDT) Omer wrote: >> OF> cpu name is cluster level, and usually the lowest common >> denominator of >> OF> the hosts in cluster, to make sure migration works in the cluster. >> >> Is there and documentation on the relationship between cpu types and >> compatibility? Right now I have a cluster per cpu type, and it might make >> sense to merge some of them if the performance hit was minimal. > = > that would be a question for qemu-kvm - they provide the cpu models we > base this on. > you can check which cpu flags you get exposed in the guest of the higher > cpu model, then check if you think your applications would care about > them... -- = Mit freundlichen Gr=C3=BC=C3=9Fen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=C3=B6nigsberger Stra=C3=9Fe 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynh= ausen --===============5138145375998606182==-- From iheim at redhat.com Sat Apr 5 17:11:02 2014 Content-Type: multipart/mixed; boundary="===============3181516297336493126==" MIME-Version: 1.0 From: Itamar Heim To: users at ovirt.org Subject: Re: [Users] Processor Type Date: Sun, 06 Apr 2014 00:10:54 +0300 Message-ID: <5340715E.3010505@redhat.com> In-Reply-To: 533FEA40.9040905@mittwald.de --===============3181516297336493126== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 04/05/2014 02:33 PM, Sven Kieske wrote: > The cpu model actually gets read from > a libvirt xml file. > > Extensive documentation about this can be found here: > http://wiki.libvirt.org/page/Libvirt_identifies_host_processor_as_a_diffe= rent_model_from_the_hardware_documentation iirc, it is still a pass-through to qemu-kvm, which accepts -cpu = . > > HTH > > Am 04.04.2014 17:32, schrieb Itamar Heim: >> On 03/31/2014 06:57 PM, Robert Story wrote: >>> On Wed, 19 Mar 2014 10:13:28 -0400 (EDT) Omer wrote: >>> OF> cpu name is cluster level, and usually the lowest common >>> denominator of >>> OF> the hosts in cluster, to make sure migration works in the cluster. >>> >>> Is there and documentation on the relationship between cpu types and >>> compatibility? Right now I have a cluster per cpu type, and it might ma= ke >>> sense to merge some of them if the performance hit was minimal. >> >> that would be a question for qemu-kvm - they provide the cpu models we >> base this on. >> you can check which cpu flags you get exposed in the guest of the higher >> cpu model, then check if you think your applications would care about >> them... > > --===============3181516297336493126==--