search for: source_remove

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