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
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.
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.
Thanks, Calvin. Can you provide more details regarding the "potentially other site-specific information" which your customers would be looking to tweak?
I guess I was referring to potential storage, application information or location specific information that may come up in a DR scenario.
Is there anything else other than network\storage that might prevent a VM to quickly import and run after the import storage domain flow?
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)
(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?
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.
Verified on - 4.1.0-0.4.master.20170105161132.gitf4e2c11.el7.centos