Bug 1277675 - [RFE] Ability to change network information in a VM import from storage domain in DR scenario
[RFE] Ability to change network information in a VM import from storage domai...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
---
x86_64 Linux
high Severity medium (vote)
: ovirt-4.1.0-beta
: 4.1.0.2
Assigned To: Yevgeny Zaspitsky
Michael Burman
: FutureFeature
Depends On: 1390560
Blocks: 1421007
  Show dependency treegraph
 
Reported: 2015-11-03 15:02 EST by Calvin Smith
Modified: 2017-02-10 00:52 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
This feature allows you to map external VNIC profiles that are defined on an imported VM to the ones that are present in the cluster the VM is going to be imported to. The previous solution exchanged all external VNIC profiles that were not present in the target cluster with an empty profile, which removed the imported VM's network functionality. Now, after importing a VM from a data domain, the VM is configured properly according to the VNIC profiles that are defined in the target cluster.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-02-01 09:39:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑4.1+
rule-engine: exception+
bmcclain: priority_rfe_tracking+
mburman: testing_plan_complete+
ylavi: planning_ack+
danken: devel_ack+
myakove: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 64536 master POST engine: Add ExternalVnicProfileMappings to ImportVmParameters 2016-11-03 09:28 EDT
oVirt gerrit 64537 master MERGED restapi: support vnic_profile_mappings in register VM 2016-11-10 08:58 EST
oVirt gerrit 64913 master MERGED Add vNic profile mapping 2016-09-29 04:27 EDT
oVirt gerrit 65139 master MERGED engine: add validation for vNic profile mappings 2016-11-10 08:58 EST
oVirt gerrit 65267 master MERGED engine: map vNic profiles according to the supplied mapping 2016-11-10 08:58 EST
oVirt gerrit 66002 master MERGED restapi: allow empty target vnic profile in the mapping 2016-11-10 09:00 EST
oVirt gerrit 66003 master MERGED engine: allow empty target vnic profile 2016-11-10 23:31 EST
oVirt gerrit 66729 master MERGED engine: Add VnicProfileViewDao.getAllForCluster method 2016-12-14 14:33 EST
oVirt gerrit 66730 master MERGED engine: add GetVnicProfilesByClusterIdQuery 2016-12-14 14:33 EST
oVirt gerrit 67379 master MERGED webadmin: introduce vNic Profile mapping popup dialog 2016-12-29 07:38 EST
oVirt gerrit 67430 master MERGED webadmin: make user selected vnic profile mapping persistent 2016-12-29 07:38 EST
oVirt gerrit 69300 ovirt-engine-4.1 MERGED webadmin: introduce vNic Profile mapping popup dialog 2016-12-29 11:13 EST
oVirt gerrit 69301 ovirt-engine-4.1 MERGED webadmin: make user selected vnic profile mapping persistent 2016-12-29 11:13 EST

  None (edit)
Description Calvin Smith 2015-11-03 15:02:02 EST
Description of problem:

When migrating a VM via moving storage domain, in some DR scenarisos the VMs will need to be brought up on a new network. This BZ is to request the implementation of a means of updating the network (and potentially other site-specific information) information as part of a virtual machine bringup after a storage pool migration.

This is not the case as of RHEV 3.5
Comment 3 Dan Kenigsberg 2016-01-28 07:02:00 EST
Calvin, are you looking for a dialog that would let you define a mapping of original vNIC profile to new vNIC profile?

This way, a user would be able to express "network 'blue' on the old site is equivalent to network 'green' in the new site".

The relevance to DR is that the mapping is easily performed when a single VM is imported. It is harder on mass import.
Comment 4 Calvin Smith 2016-02-15 15:24:52 EST
My customers would be looking at this feature from a DR perspective  in that they may have to bring up several virtual machines in a new site with a new network, so building a "blue" network and a "green" network map would be what we would be looking for.
Comment 5 Dan Kenigsberg 2016-02-16 05:54:13 EST
Thanks, Calvin. Can you provide more details regarding the "potentially other site-specific information" which your customers would be looking to tweak?
Comment 6 Calvin Smith 2016-08-02 16:08:50 EDT
I guess I was referring to potential storage, application information or location specific information that may come up in a DR scenario.
Comment 7 Yaniv Lavi (Dary) 2016-08-03 05:08:25 EDT
Is there anything else other than network\storage that might prevent a VM to quickly import and run after the import storage domain flow?
Comment 8 Michal Skrivanek 2016-08-03 05:30:44 EDT
well, sure, many other properties. From the top of my head from virt domain - display network, virtio-rng, any hostdev passthrough device, CPU type, I suppose all the quotas, QoS profiles and such, CPU pinning. We may set defaults when they don't exist on import for some, but we do not do that for all of them.
It may be alright to sacrifice some of those features (e.g. reverting to default quota)
Comment 9 Yaniv Lavi (Dary) 2016-08-21 05:28:02 EDT
(In reply to Michal Skrivanek from comment #8)
> well, sure, many other properties. From the top of my head from virt domain
> - display network, virtio-rng, any hostdev passthrough device, CPU type, I
> suppose all the quotas, QoS profiles and such, CPU pinning. We may set
> defaults when they don't exist on import for some, but we do not do that for
> all of them.
> It may be alright to sacrifice some of those features (e.g. reverting to
> default quota)

Do we save this info in the OVF?
Can we make sure we have a RFE to allow to reset these in import, so VMs can be started quickly?
Comment 10 Michal Skrivanek 2016-09-28 04:53:35 EDT
define "reset"
some can be set to default, but some should be re-mapped. The current import approach is to let map/configure only few items(VM name,network,os type) and leave the rest of parameters on user to edit using standard VM editing capabilities.
Comment 12 Michael Burman 2017-01-08 08:54:33 EST
Verified on - 4.1.0-0.4.master.20170105161132.gitf4e2c11.el7.centos

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