search for: busslotempti

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