Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-19
15:10:51 sean-k-mooney kashyap: based on https://github.com/qemu/qemu/blob/master/docs/pcie.txt it does seam to be related to Q35 but not sure its a hard dependecy
15:11:09 mriedem Placeed: it's not just you
15:11:31 hrw kashyap: thx
15:11:36 sean-k-mooney kashyap: using the Q35 chipset is likely a good idea anyway
15:11:45 Placeed mriedem : So another workaround would be to have a local disk as big as all my vm's root disk running on that server right ?
15:12:04 hrw kashyap: BP mentions q35 but right, commit can describe it more too
15:13:16 hrw kashyap: release note describes x86/q35 and aarch64/virt
15:14:48 kashyap sean-k-mooney: Okay, I double-confirmed, and indeed Q35 is a hard dep for PCIe.
15:14:55 kashyap sean-k-mooney: That doc you linked to should be updated; I'll update it
15:14:56 mriedem Placeed: i'm not sure about that
15:15:16 kashyap sean-k-mooney: But, look here (the URL from the doc you mentioned), on slide-13: https://wiki.qemu.org/images/4/4e/Q35.pdf
15:15:25 kashyap sean-k-mooney: It says: "Q35-only features: PCIe goodies [...]"
15:15:38 hrw sean-k-mooney: q35 is hard dep for pcie.
15:15:46 Placeed mriedem : What could be a workaround while i wait the official patch ?
15:16:10 sean-k-mooney kashyap: yes but the feature i was memtioning is not listed in that slide and qemu had limited pcie support before the uese of q35
15:16:11 hrw sean-k-mooney: qemu has 3 x86 platforms: isa-pc (no one uses), i440fx (pci based), q35 (pcie based)
15:16:29 mriedem Placeed: i'm not intimately familiar with the bug nor the fix - melwitt has carried the patch for a long time, so she might be able to help once she's around
15:16:31 sean-k-mooney hrw: really i taught i440fx supported pcie
15:16:42 hrw sean-k-mooney: i440fx is older than pcie ;D
15:17:13 mriedem Placeed: you could also ask about that bug in the #openstack-operators channel and ask if anyone has patched it out of tree and if so, how?
15:17:17 kashyap sean-k-mooney: Yeah, first I'll read your full comment before talking further. And yes, Q35 does have the limitation you note.
15:17:38 mriedem Placeed: i know SAP is probably doing something for it
15:17:47 mriedem they use NFS for everything, and are i think suse customers
15:18:11 Placeed mriedem : Ok thank you very very much for your help. I will also check with SUSE Guys.
15:18:58 kashyap sean-k-mooney: My second sentence in my previous message was misphrased. Correct: Q35 _solves_ that limitation of older QEMUs PCIe support.
15:19:32 hrw would be nice to see some future qemu dropping <q35 ;D
15:19:48 hrw but that's not gonna happen
15:19:56 openstack Launchpad bug 1740241 in OpenStack Compute (nova) "Network info not always displayed for a created instance" [Undecided,New]
15:19:56 bauzas stupid question but we get network information from the compute right ? https://bugs.launchpad.net/nova/+bug/1740241
15:20:06 bauzas at least until we do that from the conductor
15:21:43 mriedem efried: questoin here https://review.openstack.org/#/c/540111/5/specs/rocky/approved/update-provider-tree.rst@73
15:21:44 bauzas nevermind, got the line
15:23:43 mriedem lyarwood: are you around this week? i want to flush some ocata patches since ocata eol is supposedly next week
15:24:33 kashyap hrw: Yes, that won't happen. Majority still use the 'i440fx', as you can guess.
15:25:11 hrw yep
15:25:34 kashyap mriedem: FWIW, I at least saw him on IRC briefly in the (CET) morning
15:28:08 bauzas mriedem: I can help
15:28:36 bauzas mriedem: lemme know which ones you'd like to see reviewed
15:28:41 bauzas for the moment, looking at LP
15:30:46 mriedem bauzas: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/ocata+label:Code-Review=2
15:31:01 mriedem some of those might have things on pike yet
15:31:08 mriedem like https://review.openstack.org/#/c/539008/
15:31:13 bauzas mriedem: ack, will look at them ASAIC
15:31:20 mriedem thanks
15:31:37 bauzas 24 open bugs :p
15:31:41 bauzas woooot
15:45:48 sean-k-mooney hrw: kashyap is there a spec to enable Q35 proposed. i assume it will be via an image metadata item or perhaps a config option in the libvirt section of the nova.conf
15:46:00 kashyap sean-k-mooney: I updated the upstream QEMU doc to clearly spell out machine type requirements for PCIe features.
15:46:15 hrw sean-k-mooney: you set hw_machine_type = q35 in image and done
15:46:16 kashyap sean-k-mooney: Hmm, not that I know of; I have a TODO item to propose one, unless someone beats me to it
15:46:27 kashyap But yeah, currently what hrw tells above ^
15:46:38 hrw sean-k-mooney: and then you review https://review.openstack.org/#/c/545034/ to have slots for hotplug ;d
15:46:41 kashyap You can either set it via the machine type Nova image metadat property
15:46:47 kashyap Or via the global configuration option
15:47:26 hrw sean-k-mooney: as AArch64 porter I would love to see more and more people moving to Q35
15:47:48 kashyap sean-k-mooney: FWIW, I sent that (hopefully) clarifying patch -- https://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg04905.html
15:50:39 hrw sean-k-mooney: as then they will share similar issues as we have on aarch64 ;D
15:57:06 kashyap sean-k-mooney: So these are the two possibilities with Nova:
15:57:13 kashyap (1) Image metadata property:
15:57:19 kashyap $ openstack image set --property hw_machine_type=x86_64=pc-q35-2.10 Fedora27_Template
15:57:22 kashyap (2) Nova conf:
15:57:35 kashyap hw_machine_type=x86_64=pc-q35-2.10
15:57:35 kashyap ...
15:57:35 kashyap [libvirt]
15:58:32 kashyap sean-k-mooney: The remaining item in Nova is graceful handling of "distributions shipping 'q35' by default".
16:03:19 openstackgerrit Jay Pipes proposed openstack/os-vif master: zuul: Enable functional tests in gate https://review.openstack.org/530961
16:07:47 sean-k-mooney kashyap: yep that all makes sense to me. operator can set in in nova.conf if they want to force it by default or tenant can request it in image metadata if there image requires q35 features to work e.g. vIOMMU support
16:09:20 sean-k-mooney kashyap: hrw it seams pretty strait forward to add Q35 support so a specless blueprint might be sufficent. will ye be at the ptg next week?
16:10:59 kashyap sean-k-mooney: Yes, at least I'll be there
16:11:17 kashyap (And nod to your previous comment, too)
16:16:50 mriedem dansmith: left a comment in https://review.openstack.org/#/c/544698/2/nova/tests/unit/db/test_sqlalchemy_migration.py - if you're meh on that, then i'll +2 anyway
16:19:01 dansmith mriedem: I'm pretty meh
16:23:10 efried jaypipes, cdent: edleafe: mriedem found a discrepancy in the update_provider_tree spec that I'd like to discuss and clear up.
16:23:21 cdent was just reading that
16:23:55 efried Here's the scenario: my compute node is aggregated with a sharing provider. The sharing provider happens to be part of its own tree. We want the sharing provider itself to be included in the ProviderTree that u_p_t gets - that's for sure.
16:23:58 efried But
16:24:30 efried Do we want to include the sharing provider's whole tree? Or just the provider itself, as a "root" even if it isn't really a root in its own tree?
16:25:14 efried jaypipes: I want to say you and I discussed this briefly when I was writing the code and decided on the latter, but thinking through it again, I'm not convinced that's The Right Thing.
16:25:31 edleafe efried: sounds like you have a huge recursion problem if you include trees of trees of trees of ...
16:25:38 mriedem i assume the compute driver got an n-1 view of things it doesn't control
16:25:43 mriedem edleafe: yes agree
16:26:06 jaypipes mriedem: I don't understand what you mean by an "n-1 view"
16:26:12 efried edleafe: Well, we have explicit boundaries. We definitely don't go and spider out to the sharing provider's aggregate-associated providers.
16:26:13 mriedem 1 removed
16:26:24 efried ^ that
16:26:37 mriedem so the virt driver gets the compute node + the sharing provider aggregate, but none of that things children
16:26:39 edleafe efried: another way to look at it: would the compute node ever need to know about /interact with any of the shared provider's tree other than the SP itself?
16:26:51 efried Arguably the unrelated bits of the sharing provider's tree are n-2 - but I'm not sure that's a horrible thing.
16:27:17 cdent I think edleafe's question is the crux.
16:27:33 efried edleafe: No. But. I don't feel great about the caveat that it would show up as a root even if it's not a root. Rather have more information (that's not used) in the tree than have some of it be inaccurate?
16:27:38 mriedem if the virt driver shouldn't mess with stuff outside of the compute node's tree, it should just be able to see that there is a relationship, right? but not the whole other thing's tree, lest the virt driver gets the idea it has access to update that other thing (which it shouldn't do)
16:27:59 efried Yeah, I agree with that.
16:28:02 mriedem i can't tell if it being a root or not matters
16:28:07 efried That's the thing.
16:28:18 efried We *do* want the virt to be able to mess with the sharing provider.
16:28:19 mriedem if my virt driver shouldn't mess with the sharing provider, why do i care if it's a root or not?
16:28:37 mriedem why?
16:28:45 jaypipes mriedem: this goes back to the powervm virt driver structure.
16:28:55 cdent efried: yes we do, but for those sharing providers that we want to mess with, do we want them to existing in a nested hieararchy? I would think/hope not.
16:28:57 jaypipes mriedem: they want the ability to manage storage pools in their virt driver.

Earlier   Later