On 09/08/22 16:39, Daniel P. Berrangé wrote:
> On Thu, Sep 08, 2022 at 02:36:15PM +0100, Richard W.M. Jones wrote:
>> (Adding Dan for input)
>>
>> On Thu, Sep 08, 2022 at 03:23:41PM +0200, Laszlo Ersek wrote:
>>> On 09/08/22 10:03, Richard W.M. Jones wrote:
>>>> On Mon, Sep 05, 2022 at 01:25:27PM +0200, Laszlo Ersek wrote:
>>>>> + "p2v.vcpu.dense_topo" => manual_entry->new(
>>>>> + shortopt => "", # ignored for booleans
>>>>> + description => "
>>>>> +Copy the physical machine's CPU topology, densely populated, to the
>>>>> +guest. Disabled by default. If disabled, the C<p2v.vcpu.cores> setting
>>>>> +takes effect.",
>>>>
>>>>
>>>> I just realised I'm not completely sure what "densely populated"
>>>> means here. I think we should have a bit more explanation.
>>>>
>>>> How about something like:
>>>>
>>>> "p2v.vcpu.dense_topo" => manual_entry->new(
>>>> shortopt => "", # ignored for booleans
>>>> description => "
>>>> Copy the physical machine's complete CPU topology (sockets, cores and
>>>> threads) to the guest. Disabled by default. If disabled, the
>>>> C<p2v.vcpu.cores> setting takes effect.",
>>>>
>>>> (Which might also imply that we rename this something like
>>>> "complete_topo" or "full_topo" but I'll leave that to you.)
>>>
>>> By "dense", I meant to express that there are no gaps in the onlining of
>>> the CPU topology.
>>>
>>> Assume we have 2 sockets, 2 cores/socket, 2 theads/core. Assume CPU#1
>>> (in socket#1) is hot-pluggable, but isn't currently plugged, only CPU#0
>>> (in socket#0) is present -- making for 1*2*2 = 4 logical processors in
>>> total. A physical machine may well boot like this. Then our topology is
>>> 2*2*2, but we only have 4 logical processors, so the topology is not
>>> densely populated. The language is supposed to express that in any such
>>> case, we'll ignore the online / plugged / etc count, and we'll just grab
>>> the static topology, and fully / densely populate it with logical
>>> processors.
>>>
>>> "Complete topology" does not express this. Sticking with the above
>>> example, the topology is already complete on the physical machine (we
>>> have full information about the levels of the hierarchy), but it's not
>>> densely populated.
>>>
>>> Another example would be 1 * 4 * 2 physical (a normal low-end machine by
>>> today's standards), where the sysadmin disables (say) cores #1 and #2
>>> using /sys/devices/system/cpu/cpu{1,2}/online. (I think this may even be
>>> possible on the kernel command line, for whatever reason necessary.) In
>>> this case, during conversion, if "dense_topo" is set, we carry over not
>>> just the topology (= the 1 * 4 * 2 hierarchy), but we also densely
>>> populate it (producing 8 logical processors in the conversion output,
>>> disregarding the "gaps" on the source; i.e. that only 4 logical
>>> processors were available on the physical machine originally.)
>>>
>>> I considered "complete", and thought it didn't express my intent. "Full"
>>> is so-so -- my problem is it seems to have two meanings; one is in fact
>>> what I'm trying to say with "dense", but the other meaning is just
>>> "complete", which I don't find good.
>>>
>>> The choices p2v should offer are:
>>>
>>> - Just carry over a flat VCPU count N --> this maps to a 1 socket * N
>>> cores/socket * 1 thread / core topology, fully populated.
>>>
>>> - Otherwise (i.e., when the dense_topo knob is enabled), convert the
>>> original topology (S sockets * C/S cores/socket * T threads/core), *AND*
>>> fully populate that topology (disregarding the original "online count"
>>> on the physical machine, which may easily be less than the (S * C * T)
>>> product.)
>>
>> I think the "mot juste" has to express that we're trying to model as
>> closely as possible the real physical topology. (The denseness
>> doesn't seem to be so important - are there many machines where CPUs
>> are not online? Can that even happen when virt-p2v is running?)
>>
>> How about:
>>
>> authentic_topo
>> physical_topo
>> accurate_topo
>>
>> ...?
>>
>> The patch is totally fine, we're just quibbling about the
>> word "dense" :-)
>
> Why not 'host_topo' since it is mirroring the host ?
The physical machine on which p2v runs need not even support
virtualization -- p2v runs natively there, from inside a Live CD image.
Only the conversion output is a guest (on some other computer that does
indeed need to act as a QEMU/KVM hypervisor). Three machiens in total
are involved: the phys machine being converted to a guest, a machine
running virt-v2v (the conversion server), and then the hypervisor /
management box accepting the output guest (can be libvirt, openstack,
RHV, etc the usual output modules of virt-v2v). IOW, "host" is not
really a good fit for the machine where p2v runs.
Plus I've just finished the (difficult) rebase with the dense_topo ->
phys_topo renaming... :)
Laszlo
>
> With regards,
> Daniel
>
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
