QEMU for x86 supports two machine types, "pc" (emulating the ancient
Intel i440FX chipset originally used by the Pentium Pro), and "q35"
(https://wiki.qemu.org/Features/Q35).
Currently virt-v2v does not set any machine type, so libvirt or the
target hypervisor will choose some default, probably i4
On Thu, Jul 19, 2018 at 10:52:23AM +0200, Pino Toscano wrote:
> On Wednesday, 18 July 2018 15:37:24 CEST Richard W.M. Jones wrote:
> > The old vgscan API literally ran vgscan. When we switched to using
> > lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this
> > stopped working becaus
On Thu, Jul 19, 2018 at 03:51:04PM +0200, Tomáš Golembiovský wrote:
> +let get_ovirt_biostype guestcaps target_firmware =
> + let uefi_firmware =
> +match target_firmware with
> +| TargetBIOS -> None
> +| TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in
> + let secure_
On Thursday, 19 July 2018 15:51:04 CEST Tomáš Golembiovský wrote:
> Add oVirt specific elemnt to OVF. It represents the combination of
> machine type (i440fx/q35) and firmware (BIOS/UEFI).
Other than adding a new element in the OVF, this also enables the
conversion of UEFI guests to oVirt. It is t
Add oVirt specific elemnt to OVF. It represents the combination of
machine type (i440fx/q35) and firmware (BIOS/UEFI).
Signed-off-by: Tomáš Golembiovský
---
v2v/create_ovf.ml| 20 +++-
v2v/create_ovf.mli | 2 +-
v2v/output_rhv.ml
On Wednesday, 18 July 2018 15:37:24 CEST Richard W.M. Jones wrote:
> The old vgscan API literally ran vgscan. When we switched to using
> lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this
> stopped working because lvmetad now ignores plain vgscan commands
> without the --cache opti