| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-08 | |||
| 14:16:27 | kashyap | fried_rice: Err, sorry. I misread your comment :-) | |
| 14:17:04 | kashyap | Hmm, true, I didn't mean it to imply that way. | |
| 14:17:06 | fried_rice | kashyap: Sorry, it's a sore point for me. | |
| 14:17:13 | kashyap | No, no. It's completel fine. | |
| 14:17:28 | kashyap | I'm interested in data from other hypervisors too. Can those just chime in? | |
| 14:17:40 | fried_rice | kashyap: I appreciate how thoroughly you thought through and researched. | |
| 14:17:58 | kashyap | I just meant to share whatever data I have from a libvirt PoV. Didn't mean to say this is all "cut and dried". | |
| 14:18:10 | fried_rice | kashyap: Yeah, I pestered the relevant folks from my team yesterday to respond to that. We have scenarios where IBMi customers on POWER stripe data across literally hundreds of volumes. | |
| 14:18:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Unchain _get_phynet_info from _get_port_vnic_info https://review.openstack.org/564443 | |
| 14:18:23 | fried_rice | I'll fup and bug them again. | |
| 14:18:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Add 'create_resource_requests' to network API https://review.openstack.org/564444 | |
| 14:18:25 | openstackgerrit | Stephen Finucane proposed openstack/nova master: network: Retrieve tunneled status in '_get_network_info' https://review.openstack.org/564445 | |
| 14:19:56 | kashyap | fried_rice: I see, interesting. I don't have access to POWER machine, so certainly I don't know its limitations | |
| 14:20:02 | kashyap | (Or capabilities) | |
| 14:20:29 | kashyap | fried_rice: Also how is I/O performance across those many 100s of volumes? | |
| 14:20:30 | fried_rice | kashyap: Oh, nobody does, that's totally understandable :) | |
| 14:20:56 | fried_rice | kashyap: As I understand it, they did that striping specifically to achieve better performance. So it must be... good. | |
| 14:21:05 | fried_rice | kashyap: But I'm not the expert there. | |
| 14:21:23 | kashyap | (I suggested 256 as a potential number after looking through Kernel threads this morning, and all that testing done by the libguestfs folks.) | |
| 14:21:45 | kashyap | fried_rice: I see. I'll check with some RHT folks have access to POWER machines | |
| 14:23:45 | fried_rice | kashyap: my SME says he wants the max to be 4k :) | |
| 14:24:03 | kashyap | fried_rice: Ask them to respond with a bit more detail, please :-) | |
| 14:24:04 | mriedem | dansmith: this is for you https://review.openstack.org/#/c/490015/ | |
| 14:24:17 | fried_rice | kashyap: Yeah, I'm doing that. For some reason my guy didn't see the thread originally. | |
| 14:24:22 | dansmith | mriedem: oh boy! | |
| 14:24:50 | fried_rice | kashyap: I may wind up having to proxy his response. But one way or another we'll get it out there :) | |
| 14:24:55 | mriedem | osc didn't have host-evacuate-live so someone wants to add it | |
| 14:25:19 | dansmith | we really really should avoid more name confusion | |
| 14:25:40 | kashyap | fried_rice: Sure, noting on his behalf is fine. Just understanding the requirements of different hypervisors. If it's not too unpalatable ... we can even conditionalize based on hypervisor? | |
| 14:26:00 | fried_rice | host-evacuate-live. To me, that means "clear out this host by live-migrating all the instances off of it". So that must not be what it does. | |
| 14:26:30 | fried_rice | kashyap: That sounds like the right approach to me, and is what dansmith expressed as his first preference as well. | |
| 14:26:48 | kashyap | fried_rice: Oh, I didn't see his response yet. | |
| 14:30:34 | melwitt | mriedem, dansmith: I dunno if y'all saw but I added a -W to this https://review.openstack.org/569923 last night to signal that it's legit failing at least the xenserver, hyperv, and vmware third party CIs. so it seems there's some coordination we need to do there | |
| 14:32:20 | melwitt | oh, the tempest change that disables the virtual interfaces tests hasn't merged yet, that would explain it https://review.openstack.org/571556 | |
| 14:32:32 | melwitt | I didn't notice that last night | |
| 14:36:35 | mriedem | dansmith: yup hence my -1 on the change | |
| 14:36:43 | dansmith | mriedem: yup | |
| 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 | pvc | finucannot in order to use GPU clustering i need a vGPU supoprt right | |
| 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: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? | |