Hi, I've read the virt-v2v OpenStack output code to understand how it works and I've seen this:> (* The server name or UUID of the conversion appliance where > * virt-v2v is currently running. In future we may be able > * to make this optional and derive it from the OpenStack > * metadata service instead. > *) > server_id : string;Indeed, it can be derived from OpenStack metadata service. The following URL called from within the conversion appliance will return the metadata: http://169.254.169.254/openstack/latest/meta_data.json. As you can see, the IP address is 169.254.169.254, which will is the metadata service. The JSON body contains a uuid entry that is the current appliance UUID, hence the server_id used by virt-v2v. I don't know how to code that in OCaml, so I defer implementation to anyone with such skills. And by reading the patch, I may learn how to write small pieces of OCaml and contribute further changes :) -- *Fabien Dupont* PRINCIPAL SOFTWARE ENGINEER Red Hat - Solutions Engineering fabien@redhat.com M: +33 (0) 662 784 971 <+33662784971> <http://redhat.com> *TRIED. TESTED. TRUSTED.* Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc <https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote:> Hi,Hi Fabien, sorry I didn't respond to this earlier as I was doing some work. If you CC me on emails then you can usually get a quicker response.> I've read the virt-v2v OpenStack output code to understand how it works and > I've seen this: > > > (* The server name or UUID of the conversion appliance where > > * virt-v2v is currently running. In future we may be able > > * to make this optional and derive it from the OpenStack > > * metadata service instead. > > *) > > server_id : string; > > Indeed, it can be derived from OpenStack metadata service. The following > URL called from within the conversion appliance will return the metadata: > http://169.254.169.254/openstack/latest/meta_data.json. As you can see, the > IP address is 169.254.169.254, which will is the metadata service. The JSON > body contains a uuid entry that is the current appliance UUID, hence the > server_id used by virt-v2v.We certainly do want to do this, although there was some concern about whether the metadata service is enabled on every OpenStack instance out there. (Also there are two different types of metadata service IIRC?) In fact I tried fetching that URL from the internal OpenStack test instance that we have set up, and it doesn't work, so I suppose the metadata service isn't running. (Unfortunately the connection hung for minutes instead of timing out quickly, which is not great.) This is fine however. We should try the metadata service only if the ‘-oo server-id=...’ was not supplied.> I don't know how to code that in OCaml, so I defer implementation to anyone > with such skills. And by reading the patch, I may learn how to write small > pieces of OCaml and contribute further changes :)No real need to do it in OCaml. Easiest to string together the Curl & JSON_parser modules. https://github.com/libguestfs/libguestfs/blob/master/common/mltools/curl.mli https://github.com/libguestfs/libguestfs/blob/master/common/mltools/JSON_parser.mli What does the meta_data.json file actually look like? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On Mon, Sep 24, 2018 at 6:30 PM Richard W.M. Jones <rjones@redhat.com> wrote:> On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote: > > Hi, > > Hi Fabien, sorry I didn't respond to this earlier as I was doing some > work. If you CC me on emails then you can usually get a quicker > response. > > > I've read the virt-v2v OpenStack output code to understand how it works > and > > I've seen this: > > > > > (* The server name or UUID of the conversion appliance where > > > * virt-v2v is currently running. In future we may be able > > > * to make this optional and derive it from the OpenStack > > > * metadata service instead. > > > *) > > > server_id : string; > > > > Indeed, it can be derived from OpenStack metadata service. The following > > URL called from within the conversion appliance will return the metadata: > > http://169.254.169.254/openstack/latest/meta_data.json. As you can see, > the > > IP address is 169.254.169.254, which will is the metadata service. The > JSON > > body contains a uuid entry that is the current appliance UUID, hence the > > server_id used by virt-v2v. > > We certainly do want to do this, although there was some concern about > whether the metadata service is enabled on every OpenStack instance > out there. (Also there are two different types of metadata service IIRC?) > >This concrete approach will not work in our current deployment, since the metadata service is not there. The infrastructure was made in such a way that the IP addressing and network configuration is done on the provider side. This means that all the information VMs are getting, are coming from the lab network. I am thinking a way around this if possible. I'll try out different OSP network configurations and see if I can come up with something which will keep IP, MAC and routing consistent after migration, and still have an isolated metadata service on the OSP side.> (Unfortunately the connection hung > for minutes instead of timing out quickly, which is not great.) >yeah ... That is not the friendliest of approaches, but it waits for a pre-defined timeout someplace. Cheers, Nenad