| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-17 | |||
| 16:31:23 | Sundar | Hi sean-k-mooney: How's the deployment coming along? | |
| 16:32:04 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Remove 'test_cold_migrate_with_physnet_fails' test https://review.opendev.org/703115 | |
| 16:32:04 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Block rebuild when NUMA topology changed https://review.opendev.org/703116 | |
| 16:32:05 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703117 | |
| 16:32:05 | openstackgerrit | sean mooney proposed openstack/nova stable/rocky: FUP for in-place numa rebuild https://review.opendev.org/703118 | |
| 16:32:32 | sean-k-mooney | Sundar: i have been trying to do some backport today before the weekend so ill likely get back to it again tomorow | |
| 16:32:37 | sean-k-mooney | well monday | |
| 16:33:24 | Sundar | sean-k-mooney: NP. Have a good weekend. | |
| 16:34:39 | artom | stephenfin, https://review.opendev.org/#/c/702960/ | |
| 16:37:13 | stephenfin | artom: ta | |
| 16:42:59 | belmoreira | Hi, I'm trying to boot an aarch64 image on x86_64 compute node and initially I though would be easy... but I'm still struggling. I was assuming that I just needed to define the arch in the image and nova will use that to trigger qemu-system-arm, but apparently not. Googling about it I can't find any answer... only similar questions. Do you have any pointer? | |
| 16:43:41 | sean-k-mooney | you can only do that if you set the virt type to qemu | |
| 16:43:52 | sean-k-mooney | and then i belive you have to set a nova config option | |
| 16:44:57 | sean-k-mooney | i belive you have to configre the machine types | |
| 16:44:59 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type | |
| 16:45:43 | belmoreira | sean-k-mooney yes, I'm doing the machine type | |
| 16:47:00 | sean-k-mooney | ok then i think provide virt_type=qemu is deiend and you have the arch set in the image i think that shoudl work | |
| 16:47:30 | sean-k-mooney | you might need to set a cpu model but if you do that would force the host to only be able to run aarch64 | |
| 16:47:53 | sean-k-mooney | we do not have a way to set a cpu model per arch | |
| 16:49:12 | belmoreira | what I tried: virt_type=qemu and hw_machine_type=aarch64=machinetype1 | |
| 16:49:31 | belmoreira | also the image is set with the correct arch | |
| 16:49:35 | sean-k-mooney | what is the error you get | |
| 16:49:53 | sean-k-mooney | you might need to set [libvirt]/cpu_models | |
| 16:50:22 | belmoreira | libvirt.libvirtError: XML error: No PCI buses available | |
| 16:51:02 | sean-k-mooney | well machinetype1 is not a real machein type | |
| 16:51:19 | sean-k-mooney | it was an example for the config you need to use a real one | |
| 16:51:28 | kashyap | Yeah, belmoreira: Also any reason you're using 'virt_type' as 'qemu', instead of 'kvm'? | |
| 16:51:51 | sean-k-mooney | kashyap: because its aarch64 on x86 | |
| 16:51:53 | sean-k-mooney | so it has to be qemu | |
| 16:52:01 | kashyap | Ah, didn't read the full scroll, my bad | |
| 16:52:15 | kashyap | belmoreira: To get the supported machine types on your host, run `qemu-system-aarch64 -machine help` | |
| 16:52:27 | kashyap | (Or whatever the QEMU binary name is on your host.) | |
| 16:53:31 | sean-k-mooney | try seting hw_machine_type=aarch64=virt | |
| 16:53:35 | belmoreira | ohh :) that's the machine type | |
| 16:54:38 | sean-k-mooney | virt should be an alias to the newst arm machien type your qemu supprots | |
| 16:54:46 | sean-k-mooney | for me that is virt-4.1 | |
| 16:55:34 | sean-k-mooney | there are some specifc system it can emulate but virt is what you want mostlike with openstack | |
| 16:56:06 | kashyap | belmoreira: Yes, 'virt' is actually the _recommended_ machine type for AArch64 | |
| 16:56:09 | belmoreira | thanks for let me know what the machine type means | |
| 16:56:18 | kashyap | I've documented it "why" in the libvirt driver.py | |
| 16:56:51 | sean-k-mooney | thinks of the machine type as the "motherboard" of the vm | |
| 16:57:00 | sean-k-mooney | its not quite the same thing but its close enough | |
| 16:57:39 | kashyap | Yes, that's the analogy I use. A "virtual motherboard" with some default devices built-in | |
| 16:58:10 | sean-k-mooney | including hopefully a pci bus which is what it was previously unhappy about | |
| 16:59:07 | kashyap | sean-k-mooney: Yes, it does include | |
| 16:59:25 | kashyap | belmoreira: sean-k-mooney: I mention it in the commit message here, FWIW, https://opendev.org/openstack/nova/commit/e155baefb0 | |
| 17:02:21 | belmoreira | after changing to hw_machine_type=aarch64=virt I'm still getting the same error | |
| 17:03:50 | sean-k-mooney | kashyap: that chages the default for armv7 which is a completely different architecture | |
| 17:04:21 | sean-k-mooney | oh i guess you did it for both | |
| 17:04:24 | kashyap | Yes | |
| 17:04:35 | kashyap | sean-k-mooney: Not denying that. But the point stands, for AArch64, Armv7, etc, the recommended machine type is 'virt' :-) | |
| 17:05:19 | sean-k-mooney | belmoreira: the people that work at/with lenaro are probly your best bet | |
| 17:05:37 | sean-k-mooney | belmoreira: we have no upstream testing of cross architecure support | |
| 17:06:45 | belmoreira | sean-k-mooney kashyap thanks for your tips. I will continue to dig into this and will let you know when I find more | |
| 17:06:48 | sean-k-mooney | i have dont this with libvirt a few times in the past but never actully done it with openstack | |
| 17:08:10 | sean-k-mooney | by the way are you setting hw_machinet_type in the image too https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L60 | |
| 17:10:25 | belmoreira | In the image I just set the arch. Let me try | |
| 17:11:18 | sean-k-mooney | your setting https://github.com/openstack/glance/blob/54329c6a21b0d3f845b09e79f710fc795976a175/etc/metadefs/glance-common-image-props.json#L26-L29 | |
| 17:11:33 | sean-k-mooney | as architecture=aarch64 | |
| 17:11:44 | sean-k-mooney | or architecture=arm | |
| 17:12:23 | sean-k-mooney | sorry that should be hw_architecture=aarch64 | |
| 17:12:55 | efried | dansmith: This should hopefully be relatively simple for you to understand and sanity check if you don't mind please: https://review.opendev.org/#/c/702261/ | |
| 17:13:31 | dansmith | heh first file has random whitespace damage | |
| 17:13:34 | dansmith | but will look in a sec | |
| 17:14:46 | sean-k-mooney | belmoreira: so ya checking https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/nova/virt/arch.py#L21 it should be hw_architecture=aarch64 | |
| 17:20:05 | belmoreira | sean-k-mooney also using hw_architecture=aarch64. I'm getting the same error. Thanks. I will review my config | |
| 17:34:13 | openstackgerrit | Ilya Etingof proposed openstack/nova master: [WIP] Add JSON schema for network_data.json https://review.opendev.org/703133 | |
| 17:48:56 | openstackgerrit | sean mooney proposed openstack/nova stable/queens: Block rebuild when NUMA topology changed https://review.opendev.org/703140 | |
| 17:48:56 | openstackgerrit | sean mooney proposed openstack/nova stable/queens: Disable NUMATopologyFilter on rebuild https://review.opendev.org/703141 | |
| 17:48:57 | openstackgerrit | sean mooney proposed openstack/nova stable/queens: FUP for in-place numa rebuild https://review.opendev.org/703142 | |
| 17:53:05 | gmann | stephenfin: before you start you beer. i pushed 4-5 policies change on this, if you can check on your Monday which will be earlier than mine so pinging in advance :) - https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-defaults-refresh | |
| 17:57:23 | gibi | efried: regarding RP name parsing: Nova needs to know which PF (known by nova based on PCI address) is represented by which RP in placement. That RP is created by neutron and neutron does not use PCI addresses but uses the device name instead. So now nova also gather the device name and use that to find the device RP in placement | |
| 17:58:18 | efried | mm, okay, this is the same thing we're doing for vgpus? | |
| 17:58:33 | gibi | efried: the neutron behavior is originating from the fact that device mapping in the neutron agent config was always based on device name | |
| 17:59:13 | gibi | efried: for vgpus we don't need to agree on a common ID between diferrent projects so I guess the vgpu case is easier | |
| 17:59:27 | efried | okay, but I think we're using the name to identify the mdev, or something. | |
| 17:59:29 | efried | anyway, I get it. | |
| 17:59:34 | efried | thanks for the response. | |
| 17:59:50 | efried | I'm going through your review of provider config bottom patch fyi | |
| 17:59:58 | gibi | efried: it could be that the mdev is coming from the host OS and it is a name in the host OS not a uuid | |
| 18:00:09 | gibi | efried: thanks for the review | |
| 18:03:38 | sean-k-mooney | lyarwood: can you take a look at https://review.opendev.org/#/c/702971/ and the related patchs and the other backport to rocky and queens on monday | |
| 18:08:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Switch to hacking 2.x https://review.opendev.org/695733 | |
| 18:08:56 | openstackgerrit | Stephen Finucane proposed openstack/nova master: vif: Remove dead code https://review.opendev.org/703146 | |
| 18:08:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.libvirt' https://review.opendev.org/703147 | |
| 18:08:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.vmwareapi' https://review.opendev.org/703148 | |
| 18:08:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.hyperv' https://review.opendev.org/703149 | |
| 18:08:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.powervm' https://review.opendev.org/703150 | |
| 18:08:59 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.xenapi' https://review.opendev.org/703151 | |
| 18:08:59 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.virt.ironic' https://review.opendev.org/703152 | |
| 18:09:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve final issues with 'nova.virt' https://review.opendev.org/703153 | |
| 18:09:00 | openstackgerrit | Stephen Finucane proposed openstack/nova master: pytype: Resolve issues with 'nova.cmd', 'nova.console', 'nova.db' https://review.opendev.org/703154 | |
| 18:23:28 | efried | stephenfin: came across this: https://review.opendev.org/#/c/688603/ | |
| 18:23:28 | efried | <poke> | |
| 21:22:40 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 21:22:42 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA LM: Add func test for bug 1845146 https://review.opendev.org/687404 | |
| 21:22:42 | openstack | bug 1845146 in OpenStack Compute (nova) train "NUMA aware live migration failed when vCPU pin set" [High,Fix committed] https://launchpad.net/bugs/1845146 - Assigned to Dan Smith (danms) | |
| 22:31:49 | gibi | efried, dustinc|PTO : I've finished reviewing the provider config series. | |
| 22:32:34 | gibi | now I might dream about jsonschema in yaml files :D | |
| #openstack-nova - 2020-01-18 | |||
| 17:55:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: experiment with ProviderConfig https://review.opendev.org/703249 | |