On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
----- Original Message -----
From: "Dan Kenigsberg" <[email protected]>
To: "Laszlo Hornyak" <[email protected]>
Cc: "Yaniv Kaul" <[email protected]>, "engine-devel" <[email protected]>
Sent: Wednesday, December 5, 2012 1:55:19 PM
Subject: Re: [Engine-devel] host cpu feature
On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
----- Original Message -----
From: "Yaniv Kaul" <[email protected]>
To: "Laszlo Hornyak" <[email protected]>
Cc: "engine-devel" <[email protected]>
Sent: Wednesday, December 5, 2012 12:23:47 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
Hi,
CPU-Host support allows the virtual machines to see and utilize
the
host's CPU flags, this enables better performance in VM's, at
the
price of worse portablity.
http://www.ovirt.org/Features/Cpu-host_Support
Your feedback is welcome!
Thank you,
Laszlo
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
- I assume that when you allow migration, you'd use host-model?
This
is
not clear from the design. It seems like we VDSM developers can
choose
to use either this or passthrough, while in practice we should
support both.
I join Kaul's question: it is an ovirt-level question whether
hostPassthrough or hostModel or both should be supported. It should
not
be a unilateral vdsm decision.
Ah, possibly misunderstanding, I did not mean that VDSM should decide whether
to use host-passthrough or host-model. The engine should decide.
I meant _you_ should decide which version of vdsm api modification do you want
:)
If AllowMigrateCPUHost is set to true (in case you have the same
cpu model everywhere in your DC) migration of such hsots will be
enabled. Otherwise it will not be enabled.
What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per
cluster?
I thought of eninge-wide. The of course you can have different models in two
different DC, but they should be unique in one.
We can add this to DC or cluster level, imho it would be just another checkbox
on the UI that most users would not use.
I favor the latter; a user may have a cluster of exact-same hosts,
where
hostcpu migration is allowed, and other cluster where it is forbiden.
The nice thing about hostModel (unlike hostPassthrough) is that once
we
created the VM we can migrate it to stronger hosts, and back to the
original host. I suppose that it complicates the scheduler.
Yes with host-model you get the features that libvirt handles. In such cases
the engine could decide, if you want this functionality. Well the scheduler
architecture is just being reinvented.
For the host-passthrough, I think the AllowMigrateCPUHost configuration option
would be a simple decision for the administrator: set it to true if all hosts
are uniform. If it is not set to true, then we will not allow migration of such
VMs.
That's not what I understood from libvirt's documentation. I understood
that if you want host+migration, you need to use host-model. Otherwise -
host-passthrough.
Y.
- I'm still convinced and commented on both relevat oVirt and
libvirt
BZs that we need to add x2apic support to the CPU, regardless of
what
the host CPU exposes.
AFAIK, the KVM developers agree with me.
Not quite sure how is this related... could you send some URL's for
the bugreports?
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
