Bug 844424 - RHEVM - Admin GUI: Export domains under 3.1 DCs are created as incompatible with older DCs
RHEVM - Admin GUI: Export domains under 3.1 DCs are created as incompatible w...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
Unspecified Unspecified
high Severity high
: ---
: 3.1.0
Assigned To: Daniel Erez
vvyazmin@redhat.com
storage
:
Depends On:
Blocks: 847057
  Show dependency treegraph
 
Reported: 2012-07-30 10:36 EDT by Daniel Paikov
Modified: 2016-02-10 11:35 EST (History)
12 users (show)

See Also:
Fixed In Version: SI15
Doc Type: Bug Fix
Doc Text:
This change was introduced to maintain the domain format (V1) for the export domains compatible between the Red Hat Enterprise Virtualization 3.0 and 3.1 so that is possible to export and import virtual machines between the two different versions.
Story Points: ---
Clone Of:
: 847057 (view as bug list)
Environment:
Last Closed: 2012-12-04 15:06:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Paikov 2012-07-30 10:36:03 EDT
* Create a 3.1 DC.
* Create an Export domain under the DC.
* In the Format drop-down of the New Storage Domain dialog, the export domain is forced to be created as a V3 domain.
* This makes export domains incompatible with 3.0 DCs. It is then impossible to export VMs from a 3.0 DC into a 3.1 DC, which defeats the purpose of an export domain.
Comment 1 Federico Simoncelli 2012-07-30 11:35:43 EDT
(In reply to comment #0)
> * Create a 3.1 DC.
> * Create an Export domain under the DC.
> * In the Format drop-down of the New Storage Domain dialog, the export
> domain is forced to be created as a V3 domain.
> * This makes export domains incompatible with 3.0 DCs. It is then impossible
> to export VMs from a 3.0 DC into a 3.1 DC, which defeats the purpose of an
> export domain.

The purpose is to export images from 3.0 to 3.1, and that is why you should create the export domain in 3.0 and import it in 3.1. The opposite obviously doesn't work because V3 is a new format (which for instance contains unicode).
Comment 3 Ayal Baron 2012-07-30 16:05:28 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > * Create a 3.1 DC.
> > * Create an Export domain under the DC.
> > * In the Format drop-down of the New Storage Domain dialog, the export
> > domain is forced to be created as a V3 domain.
> > * This makes export domains incompatible with 3.0 DCs. It is then impossible
> > to export VMs from a 3.0 DC into a 3.1 DC, which defeats the purpose of an
> > export domain.
> 
> The purpose is to export images from 3.0 to 3.1, and that is why you should
> create the export domain in 3.0 and import it in 3.1. The opposite obviously
> doesn't work because V3 is a new format (which for instance contains
> unicode).

It should not be a 1-time thing.
We must support creation of a backwards compatible export domain and allow attaching it to a 3.1 DC without it being upgraded.
However, we might need to allow creation of a non backward compatible export domain to allow exporting and importing VMs with unicode (which is only supported in V3 domains.

Daniel, please note this as it might change the allowed matrix.

In any event, default should be V1 export domain (i.e. backward compatible)
Comment 4 Daniel Erez 2012-08-01 07:55:04 EDT
commit 737094cd27afe1a15c30ea69167347938b21b072

Export storage domain creation is now limited to V1 format only
(i.e. exporting and importing VMs with OVF files that contain Unicode characters won't be supported).
Comment 6 Federico Simoncelli 2012-08-01 15:40:09 EDT
(In reply to comment #4)
> commit 737094cd27afe1a15c30ea69167347938b21b072
> 
> Export storage domain creation is now limited to V1 format only
> (i.e. exporting and importing VMs with OVF files that contain Unicode
> characters won't be supported).

Does this require some collaboration from VDSM? (eg: refuse to export a VMs with unicode to V1)
Comment 7 Andrew Cathrow 2012-08-01 15:53:22 EDT
Going forward we want to have unicode support, VM names are a place where this will be required.

We should default to V3 for RHEV 3.1 but allow the user to select V1 if they wish.
We can handle the differences in documentation
Comment 8 Stephen Gordon 2012-08-09 10:48:54 EDT
Clearing release note flag, raised documentation Bug # 847057 instead.
Comment 9 Ayal Baron 2012-08-10 18:30:31 EDT
Right now we do not support unicode and do not support V3 export domains either.
The fix in this bug was to make sure export domains are always created as V1
Comment 10 Ayal Baron 2012-08-21 17:48:48 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > commit 737094cd27afe1a15c30ea69167347938b21b072
> > 
> > Export storage domain creation is now limited to V1 format only
> > (i.e. exporting and importing VMs with OVF files that contain Unicode
> > characters won't be supported).
> 
> Does this require some collaboration from VDSM? (eg: refuse to export a VMs
> with unicode to V1)

Probably, yes.

Note that current functionality is to only allow creation of V1 export domains.
Comment 11 vvyazmin@redhat.com 2012-08-23 09:59:11 EDT
Export domains are always created as V1.

Verified on RHEVM 3.1 - SI15

RHEVM: rhevm-3.1.0-13.el6ev.noarch
VDSM: vdsm-4.9.6-29.0.el6_3.x86_64
LIBVIRT: libvirt-0.9.10-21.el6.x86_64
QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.298.el6_3.x86_64
SANLOCK: sanlock-2.3-3.el6_3.x86_64

Note You need to log in before you can comment on or make changes to this bug.