search for: source_ns

Deep in the discussion of this bug, unfortunately mostly in private comments: https://bugzilla.redhat.com/show_bug.cgi?id=1594515 we decided it'd be more flexible for RHV if we had a way to map individual NICs to target networks and bridges. This can be done by adding a new --mac option so you can specify the exact mapping you need: $ virt-v2v [...] \ --mac

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- test-data/phony-guests/guests.xml.in | 8 ++++++++ v2v/input_disk.ml | 2 ++ v2v/input_libvirtxml.ml | 32

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- test-data/phony-guests/guests.xml.in | 8 ++++++++ v2v/input_disk.ml | 2 ++ v2v/input_libvirtxml.ml | 27

Those will be useful when making decisions about what configuration to set on output. The data is also included in --print-source so the tests are adjusted accordingly. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- Notes: v2: - add catch-all string-valued variants for source network and video adapter models test-data/phony-guests/guests.xml.in | 8 ++++++++

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

Where supported, pass the source CPU vendor, model and topology to the target hypervisor. For -i ova, we can get just cores per socket via a proprietary VMware extension to OVF. For -i libvirt and from virt-p2v, we can get all of these fields from the libvirt XML. For -o libvirt/local, we can preserve all of the information in the target XML. For -o glance, as far as I can tell from the

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

Instead of storing the number of sockets, cores, and threads separately with the possibility to have each of them optional, store them together, so either we have a CPU topology or none. This slightly simplifies the handling of CPU topology. Most of the output modes/producers already considered a missing information of a topology as "1" when any of the other was specified, so the

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

On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > In in-place mode, the decisions on which interfaces to use are made and > the source configuration is created by the outside entity. So in that > case v2v needs to look it up in the source configuraion, and try to > follow. > > For that, the source configuration is used to populate requested caps > object which

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

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

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

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

Mixing the XML parsing with the other functions of this module made it very hard to understand. Splitting the XML parsing into another module simplifies the flow considerably. This is just code refactoring and should not affect the semantics. --- v2v/Makefile.am | 2 + v2v/input_ova.ml | 323 +++++++++++---------------------------------- v2v/parse_ovf_from_ova.ml | 226

A couple of patches cleaning up the -i ova code. These are both just refactoring (or should be at any rate). The second patch is best viewed with 'git show -w' to exclude whitespace changes. Rich.

This patch series adds stable bus and slot numbers for removable drives (CDs and floppies) when the guest is converted using virt-v2v or virt-p2v. Previously we were a bit random about this. After this patch series, the bus and slot numbers and preserved if at all possible. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1238053 Rich.