<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 24, 2018 at 6:30 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote:<br>
> Hi,<br>
<br>
Hi Fabien, sorry I didn't respond to this earlier as I was doing some<br>
work.  If you CC me on emails then you can usually get a quicker<br>
response.<br>
<br>
> I've read the virt-v2v OpenStack output code to understand how it works and<br>
> I've seen this:<br>
> <br>
> >   (* The server name or UUID of the conversion appliance where<br>
> >    * virt-v2v is currently running.  In future we may be able<br>
> >    * to make this optional and derive it from the OpenStack<br>
> >    * metadata service instead.<br>
> >    *)<br>
> >   server_id : string;<br>
> <br>
> Indeed, it can be derived from OpenStack metadata service. The following<br>
> URL called from within the conversion appliance will return the metadata:<br>
> <a href="http://169.254.169.254/openstack/latest/meta_data.json" rel="noreferrer" target="_blank">http://169.254.169.254/openstack/latest/meta_data.json</a>. As you can see, the<br>
> IP address is 169.254.169.254, which will is the metadata service. The JSON<br>
> body contains a uuid entry that is the current appliance UUID, hence the<br>
> server_id used by virt-v2v.<br>
<br>
We certainly do want to do this, although there was some concern about<br>
whether the metadata service is enabled on every OpenStack instance<br>
out there.  (Also there are two different types of metadata service IIRC?)<br>
<br></blockquote><div><br></div><div>This concrete approach will not work in our current deployment, since the metadata service is not there.</div><div>The infrastructure was made in such a way that the IP addressing and network configuration</div><div>is done on the provider side. This means that all the information VMs are getting, are coming</div><div>from the lab network. I am thinking a way around this if possible. I'll try out different OSP network </div><div>configurations and see if I can come up with something which will keep IP, MAC and routing consistent </div><div>after migration, and still have an isolated metadata service on the OSP side. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (Unfortunately the connection hung<br>
for minutes instead of timing out quickly, which is not great.)<br></blockquote><div><br></div><div>yeah ... That is not the friendliest of approaches, but it waits for a pre-defined timeout someplace. </div><div> </div><div>Cheers,</div><div><br></div><div>Nenad</div><div> </div></div></div>