Displaying 20 results from an estimated 400 matches similar to: "[PATCH v2v v2 0/3] Use host-model"
2023 Feb 20
2
[PATCH v2v v2 3/3] -o qemu: Always use -cpu host unless overridden by source hypervisor
On 2/17/23 12:44, Richard W.M. Jones wrote:
> As with the prior commit, prefer -cpu host for all guests (except when
> we have more information from the source hypervisor). Although there
> is the disadvantage that -cpu host is non-migratable, in practice it
> would be very difficult to live migrate a host launched using direct
> qemu commands.
>
> Note that after this
2018 Jun 19
2
[PATCH] v2v: Set machine type explicitly for outputs which support it (RHBZ#1581428).
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 i440fx. Newer
versions of libvirt and QEMU will probably switch over to defaulting
2023 Mar 10
1
[V2V PATCH v3 1/6] Revert "Remove guestcaps_block_type Virtio_SCSI"
This code is needed to check whether virtio-scsi driver was installed.
This reverts commit f0afc439524853508938b2bfc758896f053462e3.
---
convert/convert.ml | 2 +-
convert/convert_linux.ml | 9 +++++++--
convert/target_bus_assignment.ml | 1 +
lib/create_ovf.ml | 1 +
lib/types.ml | 3 ++-
lib/types.mli
2023 Mar 07
1
[V2V PATCH v2 1/5] Revert "Remove guestcaps_block_type Virtio_SCSI"
This code is needed to check whether virtio-scsi driver was installed.
This reverts commit f0afc439524853508938b2bfc758896f053462e3.
---
convert/convert.ml | 2 +-
convert/convert_linux.ml | 9 +++++++--
convert/target_bus_assignment.ml | 1 +
lib/create_ovf.ml | 1 +
lib/types.ml | 3 ++-
lib/types.mli
2023 Mar 13
1
[V2V PATCH v2 1/5] Revert "Remove guestcaps_block_type Virtio_SCSI"
On 3/7/23 20:40, Andrey Drobyshev wrote:
> This code is needed to check whether virtio-scsi driver was installed.
>
> This reverts commit f0afc439524853508938b2bfc758896f053462e3.
> ---
> convert/convert.ml | 2 +-
> convert/convert_linux.ml | 9 +++++++--
> convert/target_bus_assignment.ml | 1 +
> lib/create_ovf.ml |
2023 Mar 13
1
[V2V PATCH v2 1/5] Revert "Remove guestcaps_block_type Virtio_SCSI"
On 3/13/23 10:13, Laszlo Ersek wrote:
> On 3/7/23 20:40, Andrey Drobyshev wrote:
>> This code is needed to check whether virtio-scsi driver was installed.
>>
>> This reverts commit f0afc439524853508938b2bfc758896f053462e3.
>> ---
>> convert/convert.ml | 2 +-
>> convert/convert_linux.ml | 9 +++++++--
>>
2017 Mar 16
7
[PATCH 0/4] Pass CPU vendor, model and topology from source to target.
This is tangentially related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1372668
The problem in that bug is that we didn't pass the source CPU model
(Sandybridge in that case) through to the target RHV hypervisor. So
when the Windows guest booted on the target it gives an error about
CPU hardware being disconnected (although it otherwise boots and works
fine).
This patch series
2017 Mar 17
7
[PATCH v2 0/6] v2v: Pass CPU vendor, model and topology from source to target.
v1 -> v2:
- Support for passing topology through -o glance.
- Support for passing topology through -o rhv.
- Use bool for acpi/apic/pae struct fields in virt-p2v.
- Write the xpath expression in error messages instead of file/line.
- Fix more memory leaks in virt-p2v cpuid.c.
- Passes make check & check-valgrind.
There may be some other minor changes. I believe that everything
2023 Mar 13
1
[V2V PATCH v2 1/5] Revert "Remove guestcaps_block_type Virtio_SCSI"
On 3/13/23 09:22, Andrey Drobyshev wrote:
> On 3/13/23 10:13, Laszlo Ersek wrote:
>> On 3/7/23 20:40, Andrey Drobyshev wrote:
>>> This code is needed to check whether virtio-scsi driver was installed.
>>>
>>> This reverts commit f0afc439524853508938b2bfc758896f053462e3.
>>> ---
>>> convert/convert.ml | 2 +-
>>>
2019 Apr 08
1
[PATCH] v2v: start reading the new libvirt firmware autoselect
Starting with 5.2.0, libvirt has a way to select automatically the
firmware for a guest using an attribute of the <os> tag. Hence, use
this information (when available, of course) to flag the firmware used
by the guest.
---
v2v/parse_libvirt_xml.ml | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/v2v/parse_libvirt_xml.ml b/v2v/parse_libvirt_xml.ml
index
2019 Mar 29
5
[PATCH v2 0/3] v2v: add -o json output mode
This series adds a new output mode for virt-v2v, called -o json.
It produces local files, just like -o local, although the metadata
produced is a JSON file with data that v2v collected in the conversion
process. This can be useful for converting to unsupported destinations,
still based on QEMU/KVM.
In addition to a simple different metadata, it offers a way to relocate
the disks, with
2018 Jul 19
0
[PATCH] v2v: Model machine type explicitly.
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 i440fx. The
latest advice from the QEMU and libvirt communities is not to rely on
2018 Jun 19
0
Re: [PATCH] v2v: Set machine type explicitly for outputs which support it (RHBZ#1581428).
On Tue, Jun 19, 2018 at 11:37:46AM +0100, Richard W.M. Jones wrote:
> 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
2014 May 28
2
Divide error in kvm_unlock_kick()
Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and
-cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from
the guest shortly after boot. I think is happening in kvm_unlock_kick() in the
paravirt_ops code:
divide error: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.4-guest #16
Hardware name: QEMU
2014 May 28
2
Divide error in kvm_unlock_kick()
Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and
-cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from
the guest shortly after boot. I think is happening in kvm_unlock_kick() in the
paravirt_ops code:
divide error: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.4-guest #16
Hardware name: QEMU
2019 Feb 25
7
[PATCH 0/3] RFC: v2v: add -o json output mode
This series adds a new output mode for virt-v2v, called -o json.
It produces local files, just like -o local, although the metadata
produced is a JSON file with data that v2v collected in the conversion
process. This can be useful for converting to unsupported destinations,
still based on QEMU/KVM.
In addition to a simple different metadata, it offers a way to relocate
the disks, with
2018 Jun 19
2
Re: [PATCH] v2v: Set machine type explicitly for outputs which support it (RHBZ#1581428).
On Tue, Jun 19, 2018 at 11:43:38AM +0100, Daniel P. Berrangé wrote:
> I'd encourage apps to check the capabilities XML to see what
> machine types are available.
One issue is we don't always have access to the target hypervisor.
For example in the Glance case we have to write something which will
be picked up by Nova much later:
> > + "hw_machine_type",
>
2016 Mar 11
6
[PATCH v3 0/5] v2v: more control over device types
The decision on which device type to use for disks, network and video
cards on output used to be taken deep inside the converting functions.
This is not always desirable. In particular, there are scenarios when
this decision is made before the convertion takes place. E.g. in
in-place mode, the decisions are taken and the output VM configuration
is created outside of v2v tool.
This patchset
2016 Mar 18
10
[PATCH v4 0/5] v2v: more control over device types
The decision on which device type to use for disks, network and video
cards on output used to be taken deep inside the converting functions.
This is not always desirable. In particular, there are scenarios when
this decision is made before the convertion takes place. E.g. in
in-place mode, the decisions are taken and the output VM configuration
is created outside of v2v tool.
This patchset
2016 Feb 20
8
[PATCH v2 0/4] v2v: more control over device types
The decision on which device type to use for disks, network and video
cards on output used to be taken deep inside the converting functions.
This is not always desirable. In particular, there are scenarios when
this decision is made before the convertion takes place. E.g. in
in-place mode, the decisions are taken and the output VM configuration
is created outside of v2v tool.
This patchset