| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-08 | |||
| 14:36:50 | mriedem | fried_rice: that's exactly what it does | |
| 14:36:57 | fried_rice | holy shit! | |
| 14:37:46 | mriedem | melwitt: the 3rd party CIs must not be honoring depends-on | |
| 14:37:58 | fried_rice | I know ^ is true for powervm ci. | |
| 14:38:19 | melwitt | mriedem: yeah, I didn't realize there was possibility of it working differently and not honoring | |
| 14:38:20 | fried_rice | uh, sorry, we get it for zuul but not for tox? Or something. | |
| 14:54:05 | pvc | hi | |
| 14:54:07 | pvc | anyone | |
| 14:54:59 | pvc | can i share the GPU on my compute node with 3 VMs? | |
| 14:58:01 | artom | pvc, only as of queens, with specific nvidia gpus | |
| 14:58:18 | pvc | im using quens | |
| 14:58:24 | pvc | my compute node uses GTX 1080 TI | |
| 14:59:57 | finucannot | pvc: Then no, to the best of my knowledge | |
| 15:00:16 | finucannot | You're going to need an enterprise card with vGPU support to multiplex it | |
| 15:00:42 | finucannot | Otherwise the best you can do is PCI passthrough which only allows it to be attached to one instance | |
| 15:01:27 | finucannot | pvc: https://www.openstack.org/videos/vancouver-2018/call-it-real-virtual-gpus-in-nova | |
| 15:02:50 | pvc | so if ever i launch instance with flavor property of gtx:2, i cannot use it again to launch another VM right? | |
| 15:03:08 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add requested_resources field to RequestSpec https://review.openstack.org/567267 | |
| 15:03:51 | kashyap | fried_rice: Hey, a quick question -- surely your SME has tested those 4K disks with just bare KVM? I bet they haven't tested with OpenStack... | |
| 15:04:16 | kashyap | fried_rice: Because, I doubt OpenStack as it stands will handle those many in a graceful manner, even with POWER... | |
| 15:04:16 | pvc | finucannot in order to use GPU clustering i need a vGPU supoprt right | |
| 15:04:27 | finucannot | pvc: Assuming gtx is a PCI alias, that is correct | |
| 15:04:46 | pvc | i see. thats why i can launch just one instance | |
| 15:04:59 | fried_rice | kashyap: Not KVM. POWER is a different hypervisor. The 4k disks thing was using IBMi guests, I believe. | |
| 15:05:29 | kashyap | fried_rice: Err, thinko. | |
| 15:05:32 | fried_rice | kashyap: But you're right, I doubt it was openstack - it was probably just HMC. | |
| 15:05:38 | pvc | is nvidia tesla good finucannot? | |
| 15:06:08 | melwitt | pvc: this is the support matrix for nvidia vgpu https://docs.nvidia.com/grid/latest/product-support-matrix/index.html | |
| 15:06:35 | finucannot | pvc: NVIDIA would like to say so :) I've no personal experience with that or any other enterprise-grade GPU | |
| 15:07:12 | kashyap | fried_rice: Nod. What is HMC? (My brain throws AcronymNotFound exception...) | |
| 15:07:26 | pvc | melwitt thank you so GTX does not support vGPU sad, its okay finucannot thank you btw :) | |
| 15:07:38 | kashyap | fried_rice: Ha, it must be: Hardware Management Console | |
| 15:07:41 | fried_rice | kashyap: Hardware Management Console, I think. It's the classic POWER-specific hypervisor manager | |
| 15:07:42 | fried_rice | yes | |
| 15:07:48 | kashyap | Okido; thanks | |
| 15:09:31 | fried_rice | kashyap: It's what all the old legacy POWER customers use to manage their virtualization. It's an appliance server (can be a VM or a standalone box or whatever) running a specialized MCP with the management software on it. It talks to the POWER hypervisor firmware thingy (PHYP) as well as the Virtual I/O Servers to do virtualization stuff on the system. | |
| 15:10:18 | fried_rice | kashyap: Couple years ago we forked off a thing called NovaLink, which is a similar management stack, but it lives on a plain ol' Linux VM on the POWER box itself. Idea being more scalability. | |
| 15:10:26 | kashyap | fried_rice: Ah, I see. And te modern customers use OpenStack? | |
| 15:10:28 | fried_rice | kashyap: And it is on the NovaLink partition that we run the nova-compute service. | |
| 15:10:45 | fried_rice | ...so that modern customers can use openstack, yes. | |
| 15:11:28 | kashyap | Noted; thans for the context. | |
| 15:11:31 | fried_rice | kashyap: Note the major difference from the kvm model: the NovaLink partition manages the virtualization, but the VMs don't run "in" the NovaLink partition - they run on the system itself. | |
| 15:13:10 | fried_rice | kashyap: it's a weird concept for kvm folks. Think of it this way: the NovaLink partition is a "peer" of the guest VMs. They're all "logical partitions" (LPARs) on the POWER system. | |
| 15:13:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add bandwidth related standard resource classes https://review.openstack.org/570847 | |
| 15:13:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 15:13:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 15:13:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 15:13:45 | kashyap | fried_rice: Yeah, was going to look up a bit about it to see how it compares. Thanks for the info | |
| 15:14:02 | fried_rice | kashyap: Sure thing. Thanks for listening :) | |
| 15:15:16 | kashyap | Yeah, but just to note -- anytime I suggest something that is KVM/libvirt-specific, and not seem consider other hypervisors, it's largely due to my own ignorance... | |
| 15:17:36 | mgagne | when migrating flavor in newton, this moves flavor to api database. Will CellsV1 read from that database from now on? | |
| 15:19:17 | dansmith | mgagne: you mean cellsv2? | |
| 15:19:23 | mgagne | cellsv1 | |
| 15:19:48 | mgagne | because you can still run cellsv1 in newton right? | |
| 15:20:06 | dansmith | mgagne: the api will read it from the api database yeah, but nothing else changes | |
| 15:20:23 | dansmith | mgagne: so you likely still need all the flavor replication bits or whatever you're doing I think | |
| 15:20:31 | mgagne | so will I need to create them in both api database and api/compute cells database? | |
| 15:20:35 | mgagne | right | |
| 15:20:42 | mgagne | but | |
| 15:20:51 | mgagne | db sync complains if you don't migrate them all to api db | |
| 15:21:01 | mgagne | in ocata I think | |
| 15:21:14 | dansmith | yeah, I'm trying to roll back my brain to think about this | |
| 15:21:34 | dansmith | mriedem: do you remember what belmiro said he was doing? | |
| 15:22:45 | dansmith | they have an api db in each cellsv1 cell, IIRC, and they migrated the flavors to those api databases? | |
| 15:22:50 | mgagne | I'm just trying to figure out something: I run online migration with newton. Flavors get moved to api database. But I also need to run online migration in compute cells right? (still cellsv1) Otherwise ocata complains. So I run that migration but it fails because flavors found in compute cells already exist in api database and migration fails silently with exit code 0. (and don't mark them as deleted in compute cell database) | |
| 15:23:05 | mriedem | context? | |
| 15:23:10 | mriedem | i've been in osc land all day | |
| 15:23:19 | mgagne | dansmith: they had an api db per cell due to per cell placement | |
| 15:23:20 | dansmith | mgagne: are you sharing the api database amongst all the cellsv1 cells? | |
| 15:23:28 | dansmith | ah, right, | |
| 15:23:28 | mgagne | dansmith: yes | |
| 15:23:40 | dansmith | so that's the difference between you and belmiro's approach | |
| 15:23:48 | mgagne | which I assumed was the recommended way unless you wanted per cell placement service | |
| 15:23:51 | mgagne | yes | |
| 15:23:58 | dansmith | mgagne: so you'll probably have to hack that check out | |
| 15:24:18 | dansmith | which I think actually sam mentioned in YVR in passing | |
| 15:24:31 | mgagne | ok, I don't mind hacking it. I just want to make sure that cellsv1 will read from api db now. | |
| 15:24:36 | mgagne | ok, I will rewatch the video | |
| 15:25:29 | dansmith | mgagne: it will read from the api db for things like flavor-list and nova boot... I'm not positive that there won't be other cellsv1-specific paths that aren't updated though | |
| 15:26:43 | mgagne | hehe, I understand the risk. I will rewatch the video and do some tests then. | |
| 15:27:27 | mriedem | i believe in our nova-cells v1 job the child cell doesn't have access to the api db | |
| 15:27:33 | mriedem | since we have single placement we didn't need it | |
| 15:27:37 | mgagne | right, belmiro mentioned that case in his talk | |
| 15:27:58 | dansmith | mriedem: okay I'm surprised it doesn't need it somewhere, but cool if so | |
| 15:28:07 | mgagne | I think it needs it? | |
| 15:28:22 | mriedem | or i guess they do http://logs.openstack.org/68/569268/4/gate/nova-cells-v1/545ba44/logs/etc/nova/nova-cells.conf.txt.gz | |
| 15:28:24 | mgagne | because I have it configured already. I think something complained about it. | |
| 15:28:59 | mgagne | so my bad, just a matter of paying more attention to belmiro's talk =) | |
| 15:29:26 | mriedem | 345 must be the migration that fails? | |
| 15:29:49 | mriedem | yeah.... | |
| 15:30:03 | mgagne | yes | |
| 15:30:36 | mriedem | 345 should probably have a CONF.cells.enable condition | |
| 15:30:40 | mgagne | he had a slide about those migrations | |
| 15:30:50 | mgagne | mriedem: was thinking the same ++ | |
| 15:31:10 | mriedem | but if we did that, you might not migrate your flavors to the api db and then you have other problems, i think? | |
| 15:31:24 | mriedem | we could log a warning, but likely no one would notice if db sync didn't fail | |
| 15:31:30 | mgagne | yea, that's what I'm trying to figure out | |
| 15:31:32 | mriedem | nova-status upgrade check would be good here | |
| 15:31:36 | dansmith | mriedem: yeah and looking at conf in migrations got people into trouble before, so... | |
| 15:31:58 | mriedem | if cells v1 and no flavors in api db, fail (nova-status check) | |