| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-10 | |||
| 18:18:10 | EugenMayer | i see, i try to adopt that. Can i manipualte an existing glance image or how would i introduce this? | |
| 18:18:28 | sean-k-mooney | modifying an exsiting image will not affect instnace already using it | |
| 18:18:32 | sean-k-mooney | but you can update it | |
| 18:18:44 | EugenMayer | sure, i will redo the instance. That is what i do with terraform anyhhow | |
| 18:18:53 | sean-k-mooney | genreeally if it widely used in production you will not modify it but its really a case by case decision | |
| 18:18:58 | EugenMayer | ok so it is API only i guess | |
| 18:19:30 | EugenMayer | is this an md-property? | |
| 18:19:51 | sean-k-mooney | when we create an image we "snapshot" or copy the exra specs form the flavor and metadta form the image and store a perinstance copy | |
| 18:20:01 | sean-k-mooney | that copy is then used for the lifetime of the instnace | |
| 18:20:28 | mloza | hi folks, i have two kind of computes, first one is configured to store boot disk in ceph and second is configured to store boot disk locally on the host. Both works as intendend but second one can be bypass if the user tries to boot the instance from a volume | |
| 18:20:32 | sean-k-mooney | yes these are image metadata properties | |
| 18:21:01 | sean-k-mooney | mloza: correct that is expect | |
| 18:21:28 | sean-k-mooney | if the user boots from a cinder volume that storage will always be used | |
| 18:21:58 | sean-k-mooney | so if you have a cinier providing storage via say iscsi | |
| 18:22:10 | sean-k-mooney | then the boot form volume instnace can boot on either host by default | |
| 18:22:26 | EugenMayer | sean-k-mooney: glance image-update bbcb16b8-8c84-4b01-92e8-6d66938460bf --property hw_vif_model=e1000 .. is taht what you mean by updating the image? | |
| 18:22:37 | sean-k-mooney | EugenMayer: yes exactly | |
| 18:22:58 | sean-k-mooney | if you create a new vm with that image then it should have e1000 nics instead of virtio | |
| 18:23:04 | mloza | sean-k-mooney: seems what I expected. Thanks for the info | |
| 18:23:08 | EugenMayer | ok learning. Well needless to say, but still much appretiated. Thank you so much! | |
| 18:24:19 | EugenMayer | i guess saving https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L111 and having this file as lookup makes sense. That link i store :) | |
| 18:24:37 | sean-k-mooney | EugenMayer: there is a nova doc for this too | |
| 18:24:41 | sean-k-mooney | im currently looking for it | |
| 18:25:00 | sean-k-mooney | that file is basicaly where horizon and heat get there info | |
| 18:25:03 | sean-k-mooney | to generate uis | |
| 18:25:21 | sean-k-mooney | horizone quiery glance for the set of know image properties | |
| 18:25:26 | sean-k-mooney | via the metadefs api | |
| 18:25:52 | sean-k-mooney | EugenMayer: this is glances docs on the image porperties https://docs.openstack.org/glance/latest/admin/useful-image-properties.html | |
| 18:26:23 | EugenMayer | interesting. Kind of unusual to me to have all this in a map, not a typed object. But i guess that is due to the gazzilion different names/options different hypervisors would need | |
| 18:26:44 | EugenMayer | wow that is a nice one, thanks | |
| 18:30:20 | sean-k-mooney | the actual values are defiend in a concreate object in nova | |
| 18:30:51 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L158 | |
| 18:31:15 | EugenMayer | sean-k-mooney next time when and glance operation is queued and i want to cancel, should i use `glance image-tasks` and then? i cannot see anything like stop/kill/cancel tasks when i have the ID | |
| 18:31:21 | sean-k-mooney | EugenMayer: theses are the concreate field definiton https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L293-L563 | |
| 18:33:19 | EugenMayer | This all got straight into my docs, thank you for digging those gems out | |
| 18:33:56 | EugenMayer | interesting, the interface is now available in ESXi but somehow DHCP does not work. That is unexpected | |
| 18:35:56 | opendevreview | Merged openstack/nova master: Apply common irrelevant_files for centos 8 job https://review.opendev.org/c/openstack/nova/+/817278 | |
| 18:42:30 | EugenMayer | sean-k-mooney up up and away to dinner. Thank you big times. Not sure why DHCP is not working on that ESXi, i will fiddle with that tomorrow. Have a nice evening/moring/whatever :) | |
| 18:42:44 | opendevreview | Julia Kreger proposed openstack/nova master: WIP Ironic - Reconcile compute host records on rebalance https://review.opendev.org/c/openstack/nova/+/817467 | |
| 18:49:59 | sean-k-mooney | EugenMayer: you too enjoy dinner | |
| 20:19:53 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 21:50:32 | opendevreview | Hang Yang proposed openstack/nova master: Support creating servers with RBAC SGs https://review.opendev.org/c/openstack/nova/+/811521 | |
| 22:58:12 | opendevreview | Merged openstack/nova stable/victoria: Store old_flavor already on source host during resize https://review.opendev.org/c/openstack/nova/+/810915 | |
| #openstack-nova - 2021-11-11 | |||
| 07:24:27 | EugenMayer | anybody is running a ESXi/Vmware Vsphere installation as VM under openstack and can hint me what hard interfaces are needed? Using e1000 the installer stills seems not to be able to find the NIC | |
| 08:01:08 | EugenMayer | Is it possible to install vxmnet under libvirt for openstack? https://libvirt.org/drvesx.html | |
| 08:11:00 | opendevreview | Rajat Dhasmana proposed openstack/nova-specs master: Add spec for volume backed server rebuild https://review.opendev.org/c/openstack/nova-specs/+/809621 | |
| 09:26:23 | gibi | stable cores, we need these patches to land to unblock the stable/xena placement gate https://review.opendev.org/q/topic:fix-placement-gate | |
| 09:43:05 | lyarwood | \o morning | |
| 09:44:53 | gibi | lyarwood: o/ | |
| 09:47:21 | lyarwood | ACK'd LGTM | |
| 09:51:01 | gibi | thnanks | |
| 11:32:52 | noonedeadpunk | hey everyone! is there anybody who aware of nvidia vgpus and have some little time to chat how to use them? As I have a feeling that new Ampere cards differ a lot in how they represent vgpus | |
| 11:33:36 | noonedeadpunk | the thing is that in placement I do see 32 pci devices for single gpu | |
| 11:33:44 | noonedeadpunk | each of them have 1 vgpu in placement | |
| 11:34:32 | noonedeadpunk | so feels like enabled_mdev_types is not applicable here? | |
| 11:37:00 | sean-k-mooney | mdev type is | |
| 11:37:19 | sean-k-mooney | the ampear cards support 2 types of vGPU virtualisation | |
| 11:37:46 | sean-k-mooney | you can use the same mdev based time multiplex mode that was supproted in previous gerneations | |
| 11:38:14 | sean-k-mooney | or you can use the new MIG(multi instnace GPU) feature to partion the card using sriov | |
| 11:38:16 | noonedeadpunk | well I wasn't able to get it working tbh | |
| 11:38:29 | sean-k-mooney | in this case each VF will expose a singel mdev | |
| 11:38:45 | sean-k-mooney | what nvidia does not support is using the VF via pci pasthough directly | |
| 11:38:45 | noonedeadpunk | so I just don't have mdev_bus until I run /usr/lib/nvidia/sriov-manage -e ALL | |
| 11:39:03 | sean-k-mooney | yes | |
| 11:39:12 | sean-k-mooney | that i quirk of the driver | |
| 11:39:42 | noonedeadpunk | aha, ok. I'm jsut a bit confused by amount of pci devices | |
| 11:39:43 | sean-k-mooney | noonedeadpunk: bauzas is on PTO today as its a holidy in france but they have been doing some early investigation with it have booted vms | |
| 11:39:57 | sean-k-mooney | let me see if i can get there write up | |
| 11:41:30 | noonedeadpunk | Eventually I have A10s atm, and if to follow https://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html#vgpu-types-nvidia-a10 I can get 6 vgpus of A10-4C for example. But I can hardly understand how placement would pick 6 out of these all pci devices considering every has this mdev type | |
| 11:41:53 | sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1975872#c2 is tracking our docs update for how to configure it | |
| 11:42:04 | sean-k-mooney | oh that is private hum | |
| 11:43:25 | noonedeadpunk | like https://paste.opendev.org/show/810935/ which does not make any sense to me... | |
| 11:43:57 | sean-k-mooney | why does that look odd to you | |
| 11:43:58 | noonedeadpunk | and ofc nvidia support tries their best to be not helpful... | |
| 11:44:30 | noonedeadpunk | um, because I can create only 6 vgpus of such type? | |
| 11:44:50 | noonedeadpunk | but the way more devices are repoted to placement | |
| 11:45:27 | sean-k-mooney | right ok so the nvidia smi tool basically seams to ignore the count you ask for i think that was one fo the quirks bauzas mentioned | |
| 11:45:47 | sean-k-mooney | noonedeadpunk: i think yhou will need to whitelist only a subset of the devices | |
| 11:45:52 | noonedeadpunk | you actually can't even provide to it anything | |
| 11:45:58 | noonedeadpunk | it has jsut enable or disable... | |
| 11:48:17 | noonedeadpunk | ok, thanks anyway for pointers - I will return back tomorrow I guess to catch bauzas :) | |
| 12:47:08 | lyarwood | gibi / sean-k-mooney ; finally found the change in tempest I've been talking about this week btw https://github.com/openstack/tempest/commit/e3405ba808f97eae57f3a60991000afaa34cbe89 | |
| 12:47:30 | lyarwood | wait_for_sshable=True will read console output until it see's a login: prompt | |
| 12:47:35 | lyarwood | kinda awful | |
| 12:47:40 | gibi | lyarwood: ohh | |
| 12:47:50 | gibi | lyarwood: how much slower it will make our test run? | |
| 12:48:02 | gibi | lyarwood: but anyhow, it worth to try at least | |
| 12:48:12 | lyarwood | I'm not sure tbh but I can't see how that's a valid thing to enable in Tempest | |
| 12:48:30 | lyarwood | like what says that a test image has to contain a guestOS that will actually print that? | |
| 12:49:01 | lyarwood | or configurable per tempest run and not per test | |
| 12:49:35 | sean-k-mooney | lyarwood: why | |
| 12:49:42 | sean-k-mooney | but ok i see why that is slow | |
| 12:50:02 | lyarwood | well there's nothing stopping us from using a Windows image during the test run right? | |
| 12:50:02 | sean-k-mooney | it really shoudl jsut try to ssh in a retry loop | |
| 12:50:13 | sean-k-mooney | like the pingable one did | |
| 12:50:14 | lyarwood | and that wouldn't print a login prompy | |
| 12:50:22 | lyarwood | prompt* | |
| 12:50:47 | sean-k-mooney | yes but for windows we woudl also use winrm not ssh | |
| 12:50:52 | lyarwood | and my point about making this configurable per run as opposed to per test is because you would have to go in and add this kwarg to every single create_test_server call | |
| 12:51:07 | gibi | /o\ | |