Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with. My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
After investigating alittle, it looks like it's partially supported, it uses the NoCloud portion: http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html $ tail -n 1 /etc/cloud/cloud.cfg datasource_list: ["NoCloud", "ConfigDrive"] But I'm not sure how to get more information or what's accurate. The instance ID (VM id) according to oVirt is d3f659e1-21ff-42a0-b5fa-7c2f74a36c2b However from within the VM it's a different guid: $ cat /var/lib/cloud/data/instance-id 5d753a23-6f32-41cd-947b-d45e38d30839 I'm also looking to get more information including what host it's running on, what datacenter, type of console, etc. On Wed, Mar 1, 2017 at 8:53 AM, Marc Young <3vilpenguin@gmail.com> wrote:
Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with.
My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
On Wed, Mar 1, 2017 at 4:53 PM Marc Young <3vilpenguin@gmail.com> wrote:
Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with.
We support cloud-init via config drive, not over the network.
My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
Feels OK to me - doesn't sound too hacky to me. You can do it via Ansible, but still need creds. I don't remember if anything in the VM BIOS (dmidecode) will help you there - I think not. Y.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
What feels hacky is that I have so little information about the VM i'm running from within that I'd have a hard time crawling the API enough to know the information I got was about the VM I'm testing against. Per my later email the ID in /var/lib/cloud/data/instance-id is not the same that I'd need to hit the REST API to describe On Wed, Mar 1, 2017 at 9:45 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Wed, Mar 1, 2017 at 4:53 PM Marc Young <3vilpenguin@gmail.com> wrote:
Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with.
We support cloud-init via config drive, not over the network.
My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
Feels OK to me - doesn't sound too hacky to me. You can do it via Ansible, but still need creds. I don't remember if anything in the VM BIOS (dmidecode) will help you there - I think not. Y.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 03/01/2017 04:53 PM, Marc Young wrote:
What feels hacky is that I have so little information about the VM i'm running from within that I'd have a hard time crawling the API enough to know the information I got was about the VM I'm testing against. Per my later email the ID in /var/lib/cloud/data/instance-id is not the same that I'd need to hit the REST API to describe
I'd suggest you create the virtual machines assigning them a BIOS serial number that helps you find them via the API. Easiest is to create them so that the BIOS serial number is the id of the VM in ovirt. You have an exmaple of how to set the serial number policy here: https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/set_... In your case you probably want to do this: vm_service.update( serial_number: { policy: OvirtSDK4::SerialNumberPolicy::VM } )
On Wed, Mar 1, 2017 at 9:45 AM, Yaniv Kaul <ykaul@redhat.com <mailto:ykaul@redhat.com>> wrote:
On Wed, Mar 1, 2017 at 4:53 PM Marc Young <3vilpenguin@gmail.com <mailto:3vilpenguin@gmail.com>> wrote:
Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with.
We support cloud-init via config drive, not over the network.
My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com <http://x.foo.com>" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
Feels OK to me - doesn't sound too hacky to me. You can do it via Ansible, but still need creds. I don't remember if anything in the VM BIOS (dmidecode) will help you there - I think not. Y.
_______________________________________________ Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Awesome, let me give this a shot and see if it helps On Wed, Mar 1, 2017 at 10:00 AM, Juan Hernández <jhernand@redhat.com> wrote:
On 03/01/2017 04:53 PM, Marc Young wrote:
What feels hacky is that I have so little information about the VM i'm running from within that I'd have a hard time crawling the API enough to know the information I got was about the VM I'm testing against. Per my later email the ID in /var/lib/cloud/data/instance-id is not the same that I'd need to hit the REST API to describe
I'd suggest you create the virtual machines assigning them a BIOS serial number that helps you find them via the API. Easiest is to create them so that the BIOS serial number is the id of the VM in ovirt. You have an exmaple of how to set the serial number policy here:
https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/ master/sdk/examples/set_vm_serial_number.rb
In your case you probably want to do this:
vm_service.update( serial_number: { policy: OvirtSDK4::SerialNumberPolicy::VM } )
On Wed, Mar 1, 2017 at 9:45 AM, Yaniv Kaul <ykaul@redhat.com <mailto:ykaul@redhat.com>> wrote:
On Wed, Mar 1, 2017 at 4:53 PM Marc Young <3vilpenguin@gmail.com <mailto:3vilpenguin@gmail.com>> wrote:
Ive looked through what documentation I can find and i only come up on bug reports from years ago, but: is there anyway to get metadata about a oVirt server metadata from the context of a VM ? cloud-init supports a metadata service that sits on 169.254.169.254 to retrieve info like instance-id etc. This is very useful in AWS which I'm familiar with.
We support cloud-init via config drive, not over the network.
My context is that I'd like to run some assertions against a VM and the test framework I'm using runs all assertions from within the VM itself. So If i wanted to assert that the host running my VM is "x.foo.com <http://x.foo.com>" I'd have to be able to retrieve that from within the VM. I can do that via the REST API but that requires me to get a REST user/pass inside the vm and feels hacky. The common way of doing this at openstack/aws is to curl the metadata service which replies with information only relevant to the machine asking.
Feels OK to me - doesn't sound too hacky to me. You can do it via Ansible, but still need creds. I don't remember if anything in the VM BIOS (dmidecode) will help you there - I think not. Y.
_______________________________________________ Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel <http://lists.ovirt.org/mailman/listinfo/devel>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--IScREmeGAe8TokgMCGT73cuOV6GTE7vd5 Content-Type: multipart/mixed; boundary="fdhBFjhRjrCGoD8BxK36RCrsuDwuu8rwF"; protected-headers="v1" From: Sven Kieske <s.kieske@mittwald.de> To: devel@ovirt.org Message-ID: <4e452478-1f41-040e-8f2f-0180c02a8371@mittwald.de> Subject: Re: [ovirt-devel] cloud-init metadata service References: <CAJgSuAWA8HMuC9xYSaeP3Aku=Q3yeqa_4Zd3ABauqD39nN48Rw@mail.gmail.com> <CAJgorsbXsKrtzbwp+H4VeLL0fvVwn7BQwz0Q2Va+qZcH02cvoA@mail.gmail.com> <CAJgSuAVLTOqej+jQL+zoWC2i9bGz-ONX6QuivO7EBu_3-TE9Yg@mail.gmail.com> In-Reply-To: <CAJgSuAVLTOqej+jQL+zoWC2i9bGz-ONX6QuivO7EBu_3-TE9Yg@mail.gmail.com> --fdhBFjhRjrCGoD8BxK36RCrsuDwuu8rwF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/03/17 16:53, Marc Young wrote:
What feels hacky is that I have so little information about the VM i'm running from within that I'd have a hard time crawling the API enough t= o know the information I got was about the VM I'm testing against. Per my=
later email the ID in /var/lib/cloud/data/instance-id is not the same t= hat I'd need to hit the REST API to describe
I'm glad that this is this way. =46rom a security standpoint, this would be an information leak, which enables third party users from inside the vm to attack the ovirt system. So if you implement new features in this area, I would be very very caref= ul. --=20 Mit freundlichen Gr=FC=DFen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause= n Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha= usen --fdhBFjhRjrCGoD8BxK36RCrsuDwuu8rwF-- --IScREmeGAe8TokgMCGT73cuOV6GTE7vd5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYtvEAAAoJEMby9TMDAbQRZGgP/2F6hoXvxHVXHwuh/g1zeqTu 8il12abu7FNNz1eG3zFeusV1k90At8/vQb8YGHY08gm5XSzB41MgDaKIyDkVwUBY D+86UEbZah5cBFhBknWY+RLjFP02sLTzBQSZXlbyElIJk12atFdQjERiWkDDXaXl KtUQbF7B8R9yb5Be8iWgDwyrsOQrFa3XxQ6TzDCeX54JqOawAh3d2TzmoFDnmJGb Lc8CUpBv7k1iFlRoDBqnZ4emHg5RSQnN4mJP+5R0yo2tAEs12d5bNImD/4XuTgKI zqniSZ2HKN30M0sSC22CRUvP4usTv/hB2q+mM7UWf5PmgC3BrSSbzIsATTJBWDtv P9kFZ4cm/1nfhE11DY2j5u1F+/0DTdsJFZZQv0ztAi3g1Jr17HFTyvjIpc/8i4jO umDYoB+dh+Fsc0tPOiqtqpDEI3SkLOShi8Rwvh2Yp5OQxA0rUrJ86e6SOeWjx503 N5Cxm/rUCJGb6qgVI5/kPpWCaQtlvGIxbKmvWIfObIMjwIgi52um68kFeTJW8L/O Q2euMsUpnm4FwgRzba1gOuBpdwL6DmATyqmaOBw3QapCCSxQ/tvaNY4qc1fBepMm SXLKNMqtoobtq1xMJ2xG6kZIZb9cMGP+NjFab84OjDKrEGTdtTzY/XO408Kz/RQ6 f0ApelDgAkEE0xAecFVx =GZFc -----END PGP SIGNATURE----- --IScREmeGAe8TokgMCGT73cuOV6GTE7vd5--
I partially agree. I do agree that I shouldn't have to crawl the API, nor do I want to. I'd like to have something similar to the metadata service that can provide only designated data to a request, much like how openstack/aws do it. Ie you can get _your_ instance id, network information, etc but you can't ask about neighbors' On Wed, Mar 1, 2017 at 10:04 AM, Sven Kieske <s.kieske@mittwald.de> wrote:
What feels hacky is that I have so little information about the VM i'm running from within that I'd have a hard time crawling the API enough to know the information I got was about the VM I'm testing against. Per my later email the ID in /var/lib/cloud/data/instance-id is not the same
On 01/03/17 16:53, Marc Young wrote: that
I'd need to hit the REST API to describe
I'm glad that this is this way.
From a security standpoint, this would be an information leak, which enables third party users from inside the vm to attack the ovirt system.
So if you implement new features in this area, I would be very very careful.
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Juan Hernández -
Marc Young -
Sven Kieske -
Yaniv Kaul