Displaying 14 results from an estimated 14 matches for "busslotempti".
Did you mean:
busslotempty
2015 Jul 01
0
[PATCH 7/9] v2v: Introduce the concept of target buses.
The target VM will have several buses to which disks can be attached.
Commonly it will have an IDE bus, and possibly a virtio-blk "bus" (not
really a bus) and/or a SCSI bus.
Virt-v2v does not model this at the moment. Disks are just added to
the output XML in the order that we write them, and so they can move
around with respect to the target VM.
This commit introduces the idea that
2015 Jul 01
12
[PATCH 1/9] v2v: Stable bus and slot numbers for removable drives (RHBZ#1238053).
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.
2017 Dec 08
3
[PATCH v2 0/2] v2v: -o null: Use the qemu null device driver.
This changes the infrastructure to allow the target_file to be
a QEMU URI.
Rich.
2017 Mar 16
0
[PATCH 4/4] v2v: Pass CPU vendor, model and topology from source to target.
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
2015 Oct 06
0
[PATCH 5/5] mllib: Replace various ad hoc string_* functions with String.*
This is just a straight refactoring. Various ad hoc string_*
functions that appeared in Common_utils have been renamed and placed
in the String.* namespace. The old vs "new" functions are:
string_prefix -> String.is_prefix
string_suffix -> String.is_suffix
string_find -> String.find
replace_str -> String.replace
string_nsplit -> String.nsplit
string_split
2019 Feb 25
0
[PATCH 3/3] v2v: add -o json output mode
Add a new output mode to virt-v2v: similar to -o local, the written
metadata is a JSON file with the majority of the data that virt-v2v
knowns about (or collects) during the conversion.
This is meant to be used only when no existing output mode is usable,
and a guest needs to be converted to run on KVM anyway. The user of
this mode is supposed to use all the data in the JSON, as they contain
2019 Mar 29
0
[PATCH v2 3/3] v2v: add -o json output mode
Add a new output mode to virt-v2v: similar to -o local, the written
metadata is a JSON file with the majority of the data that virt-v2v
knowns about (or collects) during the conversion.
This is meant to be used only when no existing output mode is usable,
and a guest needs to be converted to run on KVM anyway. The user of
this mode is supposed to use all the data in the JSON, as they contain
2015 Aug 11
41
[PATCH v2 00/17] v2v: add --in-place mode
This series is a second attempt to add a mode of virt-v2v operation
where it leaves the config and disk image conversion, rollback on
errors, registering with the destination hypervisor, etc. to a
third-party toolset, and performs only tuning of the guest OS to run in
the KVM-based hypervisor.
The first 14 patches are just refactoring and rearrangement of the code,
factoring the implementation
2015 Oct 06
10
[PATCH 0/5] mllib: Hide bad String functions and miscellaneous refactoring.
Hide/prevent the use of bad string functions like String.lowercase.
These are replaced by safe functions that won't break UTF-8 strings.
Other miscellaneous refactoring.
Rich.
2017 Apr 27
4
[PATCH 0/4] common: Add a simple mini-library for handling qemu command and config files.
Currently we have an OCaml library for generating the qemu command
line (used only by ‘virt-v2v -o qemu’). However we also generate a
qemu command line in ‘lib/launch-direct.c’, and we might in future
need to generate a ‘-readconfig’-compatible configuration file if we
want to go beyond 10,000 drives for scalability testing.
Therefore this patch series reimplements the qemu command line code as
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
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
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
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