|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] Heterogeneous pools question
Hi,
I looks like he is not using CPU feature levelling/masking, and his CPU does
not support it ("maskable: no"). My guess he used the force option on pool-join
to get these hosts into the same pool.
I think XCP 1.5 checks whether the CPU features match on VM migrate, whereas
previous versions did not do that. It would be nice though, if VM migrate would
take pool-other-config:cpuid_feature_mask into account, so what Eugene tried
would have worked. Currently this mask is only used for pool join.
Cheers,
Rob
> -----Original Message-----
> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-api-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of admin@xxxxxxxxxxx
> Sent: 17 February 2012 21:18
> To: xen-api@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-API] Heterogeneous pools question
>
> He should not need to force=true the migration, since he is using CPU
> feature leveling. With earlier versions of XCP, force=true is not
> required
> once CPU features are leveled. Is that no longer the case with XCP 1.5?
>
> -----Original Message-----
> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of John Else
> Sent: Friday, February 17, 2012 10:58 AM
> To: Eugene Chupriyanov; xen-api@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-API] Heterogeneous pools question
>
> Hi Eugene,
>
> If you call vm-migrate with the option "force=true" then the CPU
> compatibility check should be disabled.
>
> John
>
> -----Original Message-----
> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Eugene
> Chupriyanov
> Sent: 17 February 2012 15:56
> To: xen-api@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-API] Heterogeneous pools question
>
> Hello,
>
> I've got following problem with XCP 1.5 Beta:
> I had working pool with 2 hosts running XCP 1.1 and could use live VM
> migration back and forth between hosts.
> Bit after upgrading to XCP 1.5 Beta live migration is not working
> anymore,
> complaining to CPU incompability.
> Here is CPU info for both hosts:
> Host #1:
> cpu_count : 4
> vendor: GenuineIntel
> speed: 1995.033
> modelname: Intel(R) Xeon(R) CPU E5335 @
> 2.00GHz
> family: 6
> model: 15
> stepping: 11
> flags: fpu de tsc msr pae mce cx8 apic sep mtrr
> mca
> cmov pat clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc
> aperfmperf pni
> vmx ssse3 hypervisor tpr_shadow vnmi flexpriority
> features: 0004e33d-bfebfbff-00000001-20100800
> features_after_reboot: 0004e33d-bfebfbff-00000001-20100800
> physical_features: 0004e33d-bfebfbff-00000001-20100800
> maskable: no
>
> Host #2:
> cpu_count : 2
> vendor: GenuineIntel
> speed: 2400.158
> modelname: Intel(R) Xeon(R) CPU 3060 @
> 2.40GHz
> family: 6
> model: 15
> stepping: 6
> flags: fpu de tsc msr pae mce cx8 apic sep mtrr
> mca
> cmov pat clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc
> aperfmperf pni
> vmx est ssse3 hypervisor tpr_shadow
> features: 0000e3bd-bfebfbff-00000001-20100800
> features_after_reboot: 0000e3bd-bfebfbff-00000001-20100800
> physical_features: 0000e3bd-bfebfbff-00000001-20100800
> maskable: no
>
> I've tried to set pool-other-config:cpuid_feature_mask to
> fffbff7f-ffffffff-ffffffff-ffffffff
> But it didn't help.
>
> Is there a way to overcome this problem? Or it is not possible with new
> version?
>
> Thanks in advance,
> Eugene
>
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api
>
>
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |