Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-05-25
09:53:59 stephenfin as in libvirt version?
09:54:06 sean-k-mooney as in qemu version but ya
09:54:21 sean-k-mooney i would have to check 22.04 and rhel 9
09:54:32 sean-k-mooney but that is very new
09:54:57 stephenfin libvirt *and* qemu version
09:55:10 sean-k-mooney libvirt 8.3.0
09:55:17 sean-k-mooney not sure about the qemu version
09:55:17 stephenfin pity :(
09:55:55 sean-k-mooney initally i was also just hoping for hw:viommu=True|False
09:55:55 stephenfin would it be crazy to at least set a sane default (i.e. virtio if libvirt >= 8.3.0)?
09:56:03 stephenfin yeah, me too
09:56:31 sean-k-mooney if you want we coudl add hw:viommue=True|False and have it set it automatically
09:56:34 stephenfin also, do we want an extra spec for this. We don't traditionally do extra specs for hardware stuff
09:56:44 sean-k-mooney but we likely need a way to override
09:56:49 stephenfin I'd rather 'hw:viommu_model=auto'
09:57:03 sean-k-mooney im fine with that
09:57:05 stephenfin if we go that route and we are not turning on vIOMMU by default
09:57:15 stephenfin (why are we not doing that too btw?)
09:57:24 sean-k-mooney well ya i dont think we shoudl trun it on by default
09:57:38 sean-k-mooney turning it on by defaul?
09:57:57 sean-k-mooney i think it has negitive performance impact if you are using pci passthough
09:58:09 sean-k-mooney and it also increase memory usagein the guest
09:58:15 sean-k-mooney so it can break things
09:58:40 stephenfin So not quite a free lunch. Pity. It would be good to note that in the spec
09:59:12 sean-k-mooney stephenfin: to be clear our virt team told us not to bother enableing it because of the perfroamce impact of the intel viommu for sriov
09:59:41 stephenfin TIL. Yeah, definitely one to note on the spec
10:00:06 stephenfin Last one, do we actually want an extra spec for this? We don't traditionally do extra specs for hardware stuff
10:01:09 sean-k-mooney right normlaly it hsould be image only
10:01:34 sean-k-mooney we have broken that a few times now with the vtpm and vpmu extra specs
10:01:44 sean-k-mooney so at this point im kind of ok with it
10:02:04 sean-k-mooney if the guest does not have the driver the iommu will just not get used by the kernel in the guest i belive
10:02:19 sean-k-mooney but i have not tested that
10:04:10 opendevreview Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254
10:04:36 gibi sean-k-mooney: this is a fix for what James saw the other day downstream ^^
10:09:59 sean-k-mooney ah nice
10:11:38 sean-k-mooney gibi: can we not use the oslo stringutils str to bool function
10:11:49 sean-k-mooney i think that woudl be better
10:13:19 gibi sure, why not
10:13:21 sean-k-mooney bool_from_string
10:13:40 sean-k-mooney basiclaly whhen it becomes YES or true
10:13:46 sean-k-mooney i dont want to have to fix it again
10:16:39 gibi good point
10:16:44 gibi I will respin in a sec
10:18:00 opendevreview Balazs Gibizer proposed openstack/nova master: Accept both 1 and Y as AMD SEV KVM kernel param value https://review.opendev.org/c/openstack/nova/+/843254
10:18:05 sean-k-mooney by the way i noticed this change on more recent kernels
10:18:23 sean-k-mooney it seam all module parmater changed form 1 to y somewhwer around 5.10 ish
10:18:41 gibi I just checked mine and there it was Y
10:18:49 sean-k-mooney not sure exacatly where but i noticed it for say nested_vert for example
10:19:25 gibi hum in 5.4 it is still 1/0
10:19:33 sean-k-mooney yep
10:19:43 sean-k-mooney so i think the kernel made this change globally at some poitn
10:19:47 sean-k-mooney 1/0 still works
10:19:52 sean-k-mooney it just now reports y/n
10:20:02 sean-k-mooney in sysfs
10:20:29 sean-k-mooney i guess libvirt is just doing a raw passthough and not normalising
10:20:32 gibi hm, it is module dependent, I see modules reporting 0 on 5.17
10:20:42 sean-k-mooney oh ok
10:20:52 sean-k-mooney maybe a style change
10:20:59 gibi yeah
10:22:26 gibi OK , switched thet patch to strutils, thanks for noticing it
10:22:57 sean-k-mooney ill review it shortly just updating the iommu spec
10:23:52 gibi thanks
10:33:51 sean-k-mooney +2 by the way we will need to backport this to whenever we added sev support right
10:35:21 sean-k-mooney stephenfin: if you want to propsoe adding auto as a model please do i have no real objection to that
10:35:30 stephenfin will do
10:35:49 sean-k-mooney did you have any other outstanding questions
10:36:02 sean-k-mooney we are agreed on useign 48 for the bit with right
10:36:09 sean-k-mooney if libvirt is knew enough
10:36:59 sean-k-mooney i think that was the only other thing pending on the spec
10:37:15 sean-k-mooney well the last version was updated to say we would
10:37:44 gibi sean-k-mooney: sure I will do the backports
11:27:34 opendevreview Rajesh Tailor proposed openstack/nova master: Fix typos https://review.opendev.org/c/openstack/nova/+/843127
11:33:13 sean-k-mooney i feel philosophically oblidged to not review ^ :)
11:49:37 opendevreview Balazs Gibizer proposed openstack/nova-specs master: PCI device tracking in Placement https://review.opendev.org/c/openstack/nova-specs/+/791047
11:50:09 gibi stephenfin, sean-k-mooney, bauzas: I think all the open questions are resolved now ^^
11:54:19 sean-k-mooney ack im currntly truning some wifi setting so i might loose connectivity for a bit but ill take a look later today
11:57:33 sean-k-mooney ok that might have stablised.
11:57:43 sean-k-mooney it was till repovisioning
12:59:25 opendevreview Ade Lee proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844
13:12:52 kashyap gibi: This can be interesting: https://bugs.launchpad.net/nova/+bug/1975711. I can reproduce that too; on a fresh checkout on F36, re-run (not the first run) `tox -v pep8` is taking 3 *minutes*
13:14:50 sean-k-mooney kashyap: im not sure this is really a valid nova bug
13:15:10 sean-k-mooney this seams like its more a tox/pip issue
13:15:30 kashyap sean-k-mooney: Apparently this can be fixed in Nova, see Miguel's comment there:
13:15:33 kashyap [quote]
13:15:33 kashyap [/quote]
13:15:36 kashyap Doing this means slightly refactoring how requirements are defined in the project. I'm working on a draft patch to show what that would look like and will create a review soon.
13:15:42 kashyap He used 'pip-compile' to sort this out
13:15:43 sean-k-mooney right there fix is not really valid
13:15:54 sean-k-mooney it change how we test
13:16:08 sean-k-mooney and what we are testing
13:16:29 gibi still I guess somewhere we have some problems in the transitive dependencies as pip get stuck, while normally pip does not get stuck on a simple pep8 setup
13:17:27 gibi I agree with sean-k-mooney not to blindly alter our test process by pinning requirements. I suggest to try to find the offending dependency and try to figure out what makes it hard for pip to resolve the deps
13:17:33 sean-k-mooney if we were to fix this in nova we woudl have to delete and recreate the pinned deps every time we run tox
13:17:53 kashyap sean-k-mooney: I wouldn't be too quick to dismiss the fix without actually looking at the problem and properly understanding it.
13:17:59 sean-k-mooney and we would have to ensure that pip-compile follows UC and test-requirement properly
13:18:22 kashyap gibi: Yeah, I think I should have a trace of one of the offending deps ... lemme check
13:18:26 sean-k-mooney kashyap: im not im pointing out that they probaly dont fully understand how we test and what
13:18:39 sean-k-mooney we require form a pti point of view
13:18:56 sean-k-mooney so we need to actully see if its pti compleint and test wat we want ti to test
13:19:00 kashyap sean-k-mooney: Ah, sure. I don't deny that. (Aside, what is "pti"?)

Earlier   Later