Daniel P. Berrangé <berrange@xxxxxxxxxx> writes:
> On Tue, Mar 19, 2019 at 02:08:01PM +0100, Igor Mammedov wrote:
>> On Thu, 7 Mar 2019 10:07:05 +0000
>> Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>>
>> > On Wed, Mar 06, 2019 at 07:54:17PM +0100, Igor Mammedov wrote:
>> > > On Wed, 6 Mar 2019 18:16:08 +0000
>> > > Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
[...]
>> > > > My comments from v1 still apply. We must not do this as long as
>> > > > libvirt has no choice but to continue using this feature.
>> > > It has a choice to use 'memdev' whenever creating a new VM and continue
>> > > using 'mem' with exiting VMs.
>> >
>> > Unfortunately we don't have such a choice. Libvirt has no concept of the
>> > distinction between an 'existing' and 'new' VM. It just receives an XML
>> > file from the mgmt application and with transient guests, we have no
>> > persistent configuration record of the VM. So we've no way of knowing
>> > whether this VM was previously running on this same host, or another
>> > host, or is completely new.
>> In case of transient VM, libvirt might be able to use machine version
>> as deciding which option to use (memdev is around more than 4 years since 2.1)
>> (or QEMU could provide introspection into what machine version (not)supports,
>> like it was discussed before)
>>
>> As discussed elsewhere (v1 tread|IRC), there are users (mainly CI) for which
>> fake NUMA is sufficient and they do not ask for explicit pinning, so libvirt
>> defaults to legacy -numa node,mem option.
>> Those users do not care no aware that they should use memdev instead
>> (I'm not sure if they are able to ask libvirt for non pinned numa memory
>> which results in memdev being used).
>> This patch doesn't obsolete anything yet, it serves purpose to inform users
>> that they are using legacy option and advises replacement option
>> so that users would know to what they should adapt to.
>>
>> Once we deprecate and then remove 'mem' for new machines only (while keeping
>> 'mem' working on old machine versions). The new nor old libvirt won't be able
>> to start new machine type with 'mem' option and have to use memdev variant,
>> so we don't have migration issues with new machines and old ones continue
>> working with 'mem'.
>
> I'm not seeing what has changed which would enable us to deprecate
> something only for new machines. That's not possible from libvirt's
> POV as old libvirt will support new machines & thus we have to
> continue using "mem" for all machines in the scenarios where we
> currently use it.
We're going in circles. Igor keeps telling you QEMU needs to shed dead
weight, badly. In Igor's words:
We really need to figure out how to introduce breaking change on
management (CLI) side* in QEMU and make it digestible for libvirt
and others.
(* at least for new machine types).
You keep telling us QEMU can't ever deprecate stuff libvirt uses,
because libvirt promised forward and backward compatibility forever.
Okay, my turn to speak in absolutes.
QEMU needs to evolve, or it'll go extinct.
If we remain complacent about the rate QEMU currently evolves (and the
herculean effort evolving it often takes), QEMU will go extinct.
If we permit overambitious promises of backward compatibility to hold us
back, QEMU will go extinct.
If we permit overambitious promises *some other project made* to hold us
back, QEMU will go extinct.
End of absolutes.
I'm with Igor on this one. I'm all for QEMU going the extra mile to
help libvirt, simply because that helps a very large fraction of our
users. I'm now asking libvirt to extend the courtesy back to QEMU.
Please sit down and think earnestly about how to best soften the
compatibility promise you made so you can cope with changes we feel QEMU
has to make.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
