Bug 1277675

Summary:	[RFE] Ability to change network information in a VM import from storage domain in DR scenario
Product:	[oVirt] ovirt-engine	Reporter:	Calvin Smith <casmith>
Component:	RFEs	Assignee:	Yevgeny Zaspitsky <yzaspits>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Michael Burman <mburman>
Severity:	medium	Docs Contact:
Priority:	high
Version:	---	CC:	amureini, bmcclain, bugs, casmith, cstlaure, danken, gklein, lsurette, mburman, michal.skrivanek, myakove, rbalakri, srevivo, trichard, ykaul, ylavi
Target Milestone:	ovirt-4.1.0-beta	Keywords:	FutureFeature
Target Release:	4.1.0.2	Flags:	ylavi: ovirt-4.1+ rule-engine: exception+ bmcclain: priority_rfe_tracking+ mburman: testing_plan_complete+ ylavi: planning_ack+ danken: devel_ack+ myakove: testing_ack+
Hardware:	x86_64
OS:	Linux
Whiteboard:
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 14:39:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1390560
Bug Blocks:	1421007

Description Calvin Smith 2015-11-03 20:02:02 UTC

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 12:02:00 UTC

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 20:24:52 UTC

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 10:54:13 UTC

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 20:08:50 UTC

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 2016-08-03 09:08:25 UTC

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 09:30:44 UTC

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 2016-08-21 09:28:02 UTC

(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 08:53:35 UTC

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 13:54:33 UTC

Verified on - 4.1.0-0.4.master.20170105161132.gitf4e2c11.el7.centos