search for: virtualsystems

When writing the OVF in OVirt flavour, write the actual UUID of the VM as ovf:id attribute for <VirtualSystem>, instead of a dummy value. Suggested by Arik Hadas in https://www.redhat.com/archives/libguestfs/2018-April/msg00005.html --- v2v/create_ovf.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/create_ovf.ml b/v2v/create_ovf.ml index f56c4cb64..554374f45

When writing the OVF in OVirt flavour, write the actual UUID of the VM as ovf:id attribute for <VirtualSystem>, instead of a dummy value. Suggested by Arik Hadas in https://www.redhat.com/archives/libguestfs/2018-April/msg00005.html --- v2v/create_ovf.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/create_ovf.ml b/v2v/create_ovf.ml index ce06ce613..2fc041168

...mtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData"; - Xml.xpath_register_ns xpathctx - "vmw" "http://www.vmware.com/schema/ovf"; - Xml.xpath_register_ns xpathctx - "vssd" "http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData"; - let xpath_string = xpath_string xpathctx - and xpath_int = xpath_int xpathctx - and xpath_string_default = xpath_string_default xpathctx - and xpath_int_default = xpath_int_default xpathctx - and xpath_int64_default = xpath_int64_default xpathctx in + (* Parse...

1. AWS the name tag is not mandatory - using default as a name 2. AWD doesn't prefix 'ovf:' as prefix to disk path There is an open bug for oVirt: https://bugzilla.redhat.com/show_bug.cgi?id=1371843 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/input_ova.ml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/v2v/input_ova.ml

Instead of using ‘xpath_(string|int|int64)_default’ we can write the equivalent code using ‘Option.default’. This is not quite so concise, but may be easier to understand. eg: xpath_int_default xctx "xpath_expr" 10 -> Option.default 10 (xpath_int xctx "xpath_expr") --- common/mltools/xpath_helpers.ml | 12 ------------ common/mltools/xpath_helpers.mli | 6 ------

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.

...ponsor 0d5e092 is described below commit 0d5e092cd92d0fec1d3647d5c58c0a83d6c60b55 Author: Fabian Arrotin <arrfab at centos.org> AuthorDate: Fri Mar 20 18:18:09 2020 +0100 Added vsys.host as sponsor Signed-off-by: Fabian Arrotin <arrfab at centos.org> --- content/sponsors/virtualsystems.erb | 8 ++++++++ static/images/sponsors/vsys.png | Bin 0 -> 3120 bytes 2 files changed, 8 insertions(+) diff --git a/content/sponsors/virtualsystems.erb b/content/sponsors/virtualsystems.erb new file mode 100644 index 0000000..5da0a33 --- /dev/null +++ b/content/sponsors/virtualsystems....

...actual list Signed-off-by: Fabian Arrotin <arrfab at centos.org> --- Gemfile.lock | 2 +- _sponsors/everex.md | 7 ------- _sponsors/exabytes_my.md | 2 +- _sponsors/gamehost.md | 6 ++++++ _sponsors/virtualsystems.md | 6 ++++++ _sponsors/yourname.md | 6 ------ assets/img/sponsors/GameHost.png | Bin 0 -> 6544 bytes assets/img/sponsors/everex.png | Bin 13285 -> 0 bytes assets/img/sponsors/exabytes-my.png | Bin 5528 -> 0 bytes assets/img/sponsors/ex...

On Tue, Sep 06, 2016 at 01:52:29PM +0300, Shahar Havivi wrote: > 1. AWS the name tag is not mandatory - using default as a name > 2. AWD doesn't prefix 'ovf:' as prefix to disk path > > There is an open bug for oVirt: > https://bugzilla.redhat.com/show_bug.cgi?id=1371843 > > Signed-off-by: Shahar Havivi <shaharh@redhat.com> > > v2v/input_ova.ml | 8

On 32 bit platforms, reading the memory values can cause some numbers to be read as negative numbers. Fix this by treating memory values as 64 bit integers throughout the parsing and calculation. --- v2v/input_libvirtxml.ml | 7 ++++--- v2v/input_ova.ml | 7 ++++--- v2v/utils.ml | 15 +++++++++++++++ 3 files changed, 23 insertions(+), 6 deletions(-) diff --git

When importing from VMware via the libvirt driver, the libvirt driver can add an empty source bridge name: <interface type='bridge'> <mac address='00:01:02:03:04:05:06'/> <source bridge=''/> </interface> Replicate what we do on the -i ova path, and map these to "eth0", "eth1" etc. This also includes a bunch

Hi, v3 of these patches: https://www.redhat.com/archives/libguestfs/2018-April/msg00002.html https://www.redhat.com/archives/libguestfs/2018-April/msg00006.html Thanks, Pino Toscano (3): v2v: OVF: improve get_ostype mappings v2v: OVF: write ovirt:id attribute for the OS in OVirt flavour v2v: OVF: fix ovf:id for VirtualSystem in OVirt flavour v2v/create_ovf.ml | 253

https://bugzilla.redhat.com/show_bug.cgi?id=1570407 This turned into quite an in-depth refactoring of how we handle OVAs. It also fixes a potential security issue. Rich.

Hi, v2 of this patch: https://www.redhat.com/archives/libguestfs/2018-April/msg00003.html that includes an additional fix. Thanks, Pino Toscano (2): v2v: OVF: write ovirt:id attribute for the OS in OVirt flavour v2v: OVF: fix ovf:id for VirtualSystem in OVirt flavour v2v/create_ovf.ml | 204 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 202 insertions(+), 2

For historical reasons the OVF used in RHV export domain contains some deviations from the OVF standard. The format used in -o rhv has to remain fixed but for -o vdsm and we could produce much nicer OVF. This patch serves as a preparatory step to this. The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that

1. AWS the name tag is not mandatory - using default as a name 2. AWD doesn't prefix 'ovf:' as prefix to disk path There is an open bug for oVirt: https://bugzilla.redhat.com/show_bug.cgi?id=1371843 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/input_ova.ml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/v2v/input_ova.ml

Hi, I need to parse xml (vmware ovf) which have a namespace. Attached the ovf file. Thanks, Shahar.

The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that way. v1 -> v2: - introduced flavour types instead of booleans - instead of referring to the new flavour as "standard OVF" or "fixed OVF" I refer to it as oVirt flavour. While it is more conforming than the one used in export

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

.../v2v/test-v2v-o-vdsm-options.ovf.expected +++ b/v2v/test-v2v-o-vdsm-options.ovf.expected @@ -2,17 +2,17 @@ <ovf:Envelope xmlns:rasd='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData' xmlns:vssd='http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:ovf='http://schemas.dmtf.org/ovf/envelope/1/' ovf:version='0.9'> <!-- generated by virt-v2v 1.38.0 --> <References> - <File ovf:href='IMAGE/VOL' ovf:id='VOL'...