On 12/05/2012 07:10 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Yaniv Kaul" <yk...@redhat.com>
To: "Doron Fediuck" <dfedi...@redhat.com>
Cc: "Laszlo Hornyak" <lhorn...@redhat.com>, "engine-devel"
<engine-devel@ovirt.org>
Sent: Wednesday, December 5, 2012 6:48:33 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 06:46 PM, Doron Fediuck wrote:
----- Original Message -----
From: "Laszlo Hornyak" <lhorn...@redhat.com>
To: "Doron Fediuck" <dfedi...@redhat.com>
Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul"
<yk...@redhat.com>
Sent: Wednesday, December 5, 2012 6:41:24 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Doron Fediuck" <dfedi...@redhat.com>
To: "Laszlo Hornyak" <lhorn...@redhat.com>
Cc: "engine-devel" <engine-devel@ovirt.org>, "Yaniv Kaul"
<yk...@redhat.com>
Sent: Wednesday, December 5, 2012 5:33:35 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Laszlo Hornyak" <lhorn...@redhat.com>
To: "Yaniv Kaul" <yk...@redhat.com>
Cc: "engine-devel" <engine-devel@ovirt.org>
Sent: Wednesday, December 5, 2012 5:24:59 PM
Subject: Re: [Engine-devel] host cpu feature
----- Original Message -----
From: "Yaniv Kaul" <yk...@redhat.com>
To: "Laszlo Hornyak" <lhorn...@redhat.com>
Cc: "Dan Kenigsberg" <dan...@redhat.com>, "engine-devel"
<engine-devel@ovirt.org>
Sent: Wednesday, December 5, 2012 4:10:13 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 04:59 PM, Laszlo Hornyak wrote:
----- Original Message -----
From: "Dan Kenigsberg" <dan...@redhat.com>
To: "Yaniv Kaul" <yk...@redhat.com>
Cc: "Laszlo Hornyak" <lhorn...@redhat.com>, "engine-devel"
<engine-devel@ovirt.org>
Sent: Wednesday, December 5, 2012 3:22:18 PM
Subject: Re: [Engine-devel] host cpu feature
On Wed, Dec 05, 2012 at 04:05:00PM +0200, Yaniv Kaul wrote:
On 12/05/2012 03:55 PM, Laszlo Hornyak wrote:
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 THAT simple, Engine could take this decision
without
human
intervension.
Is there a way engine can figure out if the cpu-models in all
the
hosts are the same?
I mean even if some host flags are not handled by libvirt and
therefore vdsm and engine...
So I would really need that permission from the user.
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
You may be right, could you send an URL to that point of
the
documentation or copy-paste?
The link I followed from your feature page:
http://libvirt.org/formatdomain.html#elementsCPU :
host-model
The host-model mode is essentially a shortcut to copying
host
CPU
definition from capabilities XML into domain XML. Since the
CPU
definition is copied just before starting a domain, exactly
the
same
XML can be used on different hosts while still providing
the
best
guest CPU each host supports. Neither match attribute nor
any
feature elements can be used in this mode. Specifying CPU
model
is
not supported either, but model's fallback attribute may
still
be
used. Libvirt does not model every aspect of each CPU so
the
guest
CPU will not match the host CPU exactly. On the other hand,
the
ABI
provided to the guest is reproducible. During migration,
complete
CPU model definition is transferred to the destination host
so
the
migrated guest will see exactly the same CPU model even if
the
destination host contains more capable CPUs for the running
instance
of the guest; but shutting down and restarting the guest
may
present
different hardware to the guest according to the
capabilities
of
the
new host.
host-passthrough
With this mode, the CPU visible to the guest should be
exactly
the
same as the host CPU even in the aspects that libvirt does
not
understand. Though the downside of this mode is that the
guest
environment cannot be reproduced on different hardware.
Thus,
if
you
hit any bugs, you are on your own.
That's exactly where AllowMigrateCPUHost fits well: when a
user
ticks
this for a cluster he says "yeah, I like to be on my own."
cpu mode="host-passthrough" migration: I talked to the
libvirt
guys
and they said it is OK if the hardware and the software are
the
same, and it will work, but they would not recommend.
So if they do not recommend it, I would drop this from the
feature
spec. Anyone against it?
Laszlo
I'm a bit against it. I don't see why it's that complicated:
Allow migration -> use 'host-model'
Do not allow -> use 'host-passthrough'.
So the actual cpu capabilities would depend not only on the
'host
cpu' checkbox, but also on the 'pinned to host' checkbox. I
think
this logical trick would be both funny and confusing from the
user's
perspective.
The reason of why we need host-passthrough is that otherwise I
suspect
we depend on libvirt for newer features to be somehow exposed
to
the
guest (not sure about it).
Yes, with other words: this is a tuning feature.
Let's keep it simple.
1. Please remove AllowMigrateCPUHost. No reason for us to do what
libvirt is asking to void.
With pleasure :)
2. host-passthrough should be available only for non migratable
VMs.
Right.
And no host-model support for now, right?
Right.
In can later be added if we have a good reasoning for it.
Alternative idea, inspired by "Thus, if you hit any bugs, you are on
your own" (http://libvirt.org/formatdomain.html#elementsCPU wrt
'host-passthrough'):
A config option to determine if we use host-model or
host-passthrough.
Y.
I do not think the engine should go to this level.
IMHO, it's not the engine, it's the user - the advanced user. But even
an advanced user won't go and change VDSM's logic.
Lets hope that host-passthrough is well tested.
Y.
ie- it can ask for passthrough as a feature, and the
actual implementation is handled by vdsm.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
