Displaying 20 results from an estimated 30 matches for "source_remove".
Did you mean:
g_source_remove
2016 Feb 09
0
[PATCH 1/4] v2v: collect source network and video adapter types
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
2016 Mar 18
0
[PATCH v4 1/5] v2v: collect source network and video adapter types
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
2016 Feb 20
0
[PATCH v2 1/4] v2v: collect source network and video adapter types
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 ++++++++
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
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 +++++++--
>>
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 +-
>>>
2016 Apr 14
0
[PATCH v2] v2v: add support for virtio-scsi
Virtio-SCSI offers a number of advantages over virtio-blk, in
particular, it supports SCSI UNMAP (aka trim) which is crucial for
keeping the virtual drive from wasting host disk space.
This patch adds support for virtio-scsi as the virtual disk connection
type both on input and on output of v2v.
Virtio-blk remains the default, so for now virtio-scsi-based guests can
only be produced in
2016 Apr 14
1
[PATCH v4] v2v: add support for virtio-scsi
Virtio-SCSI offers a number of advantages over virtio-blk, in
particular, it supports SCSI UNMAP (aka trim) which is crucial for
keeping the virtual drive from wasting host disk space.
This patch adds support for virtio-scsi as the virtual disk connection
type both on input and on output of v2v.
Virtio-blk remains the default, so for now virtio-scsi-based guests can
only be produced in
2008 Mar 26
1
Souffleur project patches
...t; MediaInfo.py.diff
Fixed broken import message
-> souffleur.glade.diff
A general GUI cleanup to make it look simpler
-> Souffleur.py.diff
Adapted the code to use new GPlayer.py functionality
Added a gobject.source_remove for update polling
callback when video stream is paused
Added a new column to the subtitles ListStore to display
subtitle number
Please beware that I am not an experienced programmer and this is my
first contribution to an opensource project.
Critiques are more then welcome...
2023 Feb 22
0
[V2V PATCH 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
2016 Apr 14
1
[PATCH v3] v2v: add support for virtio-scsi
Virtio-SCSI offers a number of advantages over virtio-blk, in
particular, it supports SCSI UNMAP (aka trim) which is crucial for
keeping the virtual drive from wasting host disk space.
This patch adds support for virtio-scsi as the virtual disk connection
type both on input and on output of v2v.
Virtio-blk remains the default, so for now virtio-scsi-based guests can
only be produced in
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
2017 Nov 02
3
[PATCH 0/2] v2v: Handle SATA controller (RHBZ#1508874).
https://bugzilla.redhat.com/show_bug.cgi?id=1508874
Also avoids a warning.
Rich.
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.
2016 Apr 12
3
[PATCH] v2v: add support for virtio-scsi
Virtio-SCSI offers a number of advantages over virtio-blk, in
particular, it supports SCSI UNMAP (aka trim) which is crucial for
keeping the virtual drive from wasting host disk space.
This patch adds support for virtio-scsi as the virtual disk connection
type both on input and on output of v2v.
Virtio-blk remains the default, so for now virtio-scsi-based guests can
only be produced in
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
2018 Apr 20
1
[PATCH] v2v: rework handling of CPU topology
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