For patches 4-9 (and so the whole series):
Reviewed-by: Richard W.M. Jones
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
On Wed, Apr 20, 2022 at 06:23:27PM +0200, Laszlo Ersek wrote:
> In the match on (s_cpu_vendor, s_cpu_model), the following expression is
> duplicated:
>
> e "model" ["fallback", "allow"] [PCData model]
>
> For eliminating this, normalize the match: match each component in
> separation, in the
On Wed, Apr 20, 2022 at 06:23:26PM +0200, Laszlo Ersek wrote:
> Squash the patterns
>
> | None, None -> ()
> | Some _, None -> ()
>
> into the identical
>
> | _, None -> ()
>
> We preserve the behavior added by commit 2a576b7cc5c3 ("v2v: -o libvirt:
> Don't write only without
On Wed, Apr 20, 2022 at 06:23:25PM +0200, Laszlo Ersek wrote:
> + gcaps_default_cpu : bool;
> + (** True iff the guest OS is capable of running on QEMU's default VCPU
> model.
Can we say “(eg. -cpu qemu64)” here? Might be easier than trying to
parse what QEMU's default VCPU means.
Rest looks
On Wed, Apr 20, 2022 at 05:14:26PM +0200, Tomáš Golembiovský wrote:
> oVirt API call for VM creation finishes before the VM is actually
> created. Entities may be still locked after virt-v2v terminates and if
> user tries to perform (scripted) actions after virt-v2v those operations
> may fail. To
On 04/20/22 18:23, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2076013
>
> We don't specify a VCPU model in the destination domain description if
> the source description doesn't specify one. This is a problem for x86-64
> RHEL-9.0+ guests, when using the QEMU or
On Tue, Apr 19, 2022 at 05:24:15PM +0200, Laszlo Ersek wrote:
> See also:
>
> - virt-v2v commit 75872bf282d7 ("input: -i vmx: Add support for NVMe
> devices", 2022-04-08),
>
> - libvirt commit 2214fe90442c ("vmx: start parsing SATA disks",
> 2020-10-14).
>
> Bugzilla:
On Tue, Apr 19, 2022 at 05:24:14PM +0200, Laszlo Ersek wrote:
> The "s_disk_id" field is supposed to be unique across all fixed disks of
> the source domain.
>
> With "-i vmx -it ssh" however, we restart assigning "s_disk_id" from zero
> near the end of the "find_hdds" function.
>
> The problem
Commit 2a576b7cc5c3 ("v2v: -o libvirt: Don't write only without
(RHBZ#1591789).", 2018-06-21) introduced a path in the code where
we create a childless
element. Namely, after said commit, in case
source.s_cpu_vendor <> None &&
source.s_cpu_model = None &&
source.s_cpu_topology = None
RHEL >= 9.0 on x86_64 requires the processor to support the "x86-64-v2"
microarchitecture level, which the default QEMU VCPU model does not
satisfy. Activate host-passthrough for such guest OSes.
(Libosinfo does not track processor support, so in the future we may have
to extend the expression
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2076013
We don't specify a VCPU model in the destination domain description if
the source description doesn't specify one. This is a problem for x86-64
RHEL-9.0+ guests, when using the QEMU or libvirt output modules. Those
outputs default to
In the match on (s_cpu_vendor, s_cpu_model), the following expression is
duplicated:
e "model" ["fallback", "allow"] [PCData model]
For eliminating this, normalize the match: match each component in
separation, in the proper order, creating a tree-like match rather than a
table-like one.
This
Squash the patterns
| None, None -> ()
| Some _, None -> ()
into the identical
| _, None -> ()
We preserve the behavior added by commit 2a576b7cc5c3 ("v2v: -o libvirt:
Don't write only without (RHBZ#1591789).", 2018-06-21);
the change only simplifies the code.
Bugzilla:
The 'match="minimum"' attribute of the element only makes sense if
the CPU model is specified. If the CPU model is not specified by
"s_cpu_model", i.e., we produce the element only due to
"s_cpu_topology", then we need no attributes for at all. Restrict
'match="minimum"' to when "s_cpu_model"
If "s_cpu_model" is None and "gcaps_default_cpu" is "false", generate the
element for libvirt.
This element produces an (almost) exact copy of the host (i.e., physical)
CPU for the guest, which is the best choice for guest OSes that cannot run
on QEMU's default VCPU type -- considering that
At the moment, QEMU is always started with the default "qemu64" VCPU
model, even if the source hypervisor sets a particular VCPU model.
"qemu64" is not suitable for some guest OSes. Honor "source.s_cpu_model"
via the "-cpu" option, if the source specifies the VCPU model. The logic
is basically
Conversion will set "gcaps_default_cpu" to true iff the guest OS is
capable of running on QEMU's default VCPU model.
This capability will only matter for the QEMU and libvirt output modules,
where, in case the capability is false *and* the source hypervisor does
not specify a VCPU model, we'll
If "s_cpu_model" is None and "gcaps_default_cpu" is "false", generate the
"-cpu host" option for QEMU.
"-cpu host" produces an (almost) exact copy of the host (i.e., physical)
CPU for the guest, which is the best choice for guest OSes that cannot run
on QEMU's default VCPU type -- considering
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion.
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion.
20 matches
Mail list logo
