Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-07
16:43:39 stephenfin sean-k-mooney: Awesome. So one provider network will be associated with one physnet. I assume you could have multiple provider networks using the same physnet?
16:43:54 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
16:43:57 stephenfin Not that you'd want to/need to, but out of curiosity
16:44:08 sean-k-mooney stephenfin: that depend on the network type
16:44:42 sean-k-mooney you can only have one flat network per provider but you can also have 4096 vlan networks and 4096^2 QinQ networks
16:46:00 stephenfin sean-k-mooney: Ah, ok, so the VLAN case is why we should track physnet for that configuration option rather than provider network
16:46:01 sean-k-mooney its common to use the flat network as you wan uplink and then vlan networks for tenants on a singel physnet
16:47:07 andreaf mriedem I think that's something that changed on Tempest side because it used to work
16:47:12 stephenfin Seeing as each provider network will be using the same physical network and therefore the same OVS bridge and NICs (in the simple case)
16:47:40 andreaf mriedem the regex I mean - mtreinish could be something related to the changes we had around tempest run recently?
16:49:55 sean-k-mooney stephenfin: yes. this is why you dont want to use network affinity but rather us the physnet to aggregate many networks
16:50:59 stephenfin sean-k-mooney: Excellent. Thanks for the info :)
16:52:20 sean-k-mooney stephenfin: this might be useful too https://github.com/openstack/neutron/blob/master/doc/source/admin/intro-os-networking.rst#provider-networks
16:52:55 stephenfin sean-k-mooney: Sounds good. I'd been relying on this one so far https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/networking_guide/sec-connect-instance#using_flat_provider_networks
16:54:07 claudiub stephenfin: that looks like a spec-ial ocasion for a guiness. :D
16:54:39 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe ports https://review.openstack.org/545034
16:55:03 hrw stephenfin: comments addressed. channel was not publically logged from what I see so no log
16:55:18 stephenfin hrw: Cool. Thanks for checking that out
16:55:31 hrw stephenfin: thanks for looking ;)
16:56:07 hrw stephenfin: like I said at PTG: addressing comments quickly allows to keep reviewer's attention to go for a second look ;)
16:57:12 openstackgerrit Dan Smith proposed openstack/nova master: Run post-test archive against cell1 https://review.openstack.org/550194
16:57:13 openstackgerrit Dan Smith proposed openstack/nova master: Add simple db purge command https://review.openstack.org/550171
16:57:13 openstackgerrit Dan Smith proposed openstack/nova master: Add --purge helper flag to archive_deleted_rows https://review.openstack.org/550182
16:57:14 openstackgerrit Dan Smith proposed openstack/nova master: Make nova-manage db purge take --all-cells https://review.openstack.org/550502
16:57:46 stephenfin hrw: I kind of think that warning is necessary. If you don't have that, how will the operator know their specially configured option is doing zilch?
16:57:46 sean-k-mooney stephenfin: its rather old but i used to send people this https://web.archive.org/web/20151006051825/https://www.rdoproject.org//Networking_in_too_much_detail to understand how openstack networking works with ovs but the offical netwoking guide is now pretty good too
16:57:52 idlemind holy fork; if i manually edit the vm w/virsh and add <feature policy='require' name='svm'>/> and reboot the instance in openstack i get svm passed into the guest ... i imagine this could get lost if the vm is migrated?
16:57:54 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
16:58:34 hrw stephenfin: are there all options covered with such warning?
16:58:37 idlemind and there doesn't seem to be a way to force feature policy 'require' into kvm / libvirt vm definitions am i right?
16:58:45 idlemind (through metadata of an image)
16:58:47 hrw stephenfin: openstack logs are already overloaded with text in them
16:59:03 sean-k-mooney idlemind: it will remain untill a hard reboot is done or any other event that cause the xml to be regenerated(migration resize, hard reboot)
16:59:11 hrw like 100 characters of some random uuid like stuff before any useful data goes
16:59:31 idlemind sean-k-mooney thanks; anyway to get openstack to persistently add a feature 'require' statement for libvirt?
17:00:02 sean-k-mooney idlemind: i belive there is a way via image metadata
17:00:04 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: hyper-v: Logs tips on PortBindingFailed https://review.openstack.org/550529
17:00:39 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612
17:01:03 stephenfin hrw: We do tend to warn for things like that alright, e.g. [1]. Not sure how consistent we are though. [1] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L548-L562
17:01:26 stephenfin hrw: I could be wrong though. Perhaps mriedem or someone could weigh in?
17:01:45 hrw stephenfin: those you linked are close to log.error() level like
17:01:55 idlemind sean-k-mooney i've been trying but failing it would seem cim_pasd_instructionsetextension seems to be close but those values don't trickle into libvirt at least w/host-passthrough on
17:02:10 stephenfin Doesn't that seem sane though? I mean, we told nova to do something and it can't do it
17:02:19 stephenfin Someone should probably be told about that
17:02:27 mriedem what is the question?
17:02:45 stephenfin mriedem: comment here https://review.openstack.org/#/c/545034/13/nova/virt/libvirt/driver.py
17:02:46 hrw stephenfin: those warnings you linked are 'read, fix or things may blow' rather than 'ouch, you set option you do not need'
17:02:54 sean-k-mooney idlemind: what is you usecase that you want to enable
17:03:11 sean-k-mooney you want to froce requiring kvm?
17:03:50 idlemind sean-k-mooney guests that can run accelerated vm's (gns3 server, labs, etc) my hardware is amd and nova is running natively there
17:04:12 stephenfin hrw: It's more 'ouch, you set an option that won't work'. If they set the option, they were probably trying to work around an issue (I imagine)
17:04:21 stephenfin fwiw, I'd also be fine with 'LOG.info' too.
17:04:25 sean-k-mooney idlemind: you want to enable nested virt?
17:04:30 idlemind ya
17:05:17 sean-k-mooney generally the best way to do that is to set the cpu_mode option in the libvirt section to host-passthrough and enable nested virt on the host kernel module
17:05:36 hrw stephenfin: can I ask for LOG.warning/info() for hyperv on aarch64 checks? cause for me this is this level of stuff. You set an option which is useless in your config.
17:05:49 hrw s/You/operator
17:06:52 hrw stephenfin: I may be wrong but I expect people to know why they are changing random config options
17:07:46 mriedem stephenfin: replied
17:09:05 stephenfin hrw: Not really the same thing - this is a libvirt/qemu option so that would matter if someone were using the libvirt/qemu driver
17:09:13 stephenfin BUT, that said, I get your point
17:09:19 hrw mriedem: thanks. https://review.openstack.org/#/c/545034/14/nova/conf/libvirt.py got improved a bit
17:09:21 mriedem stephenfin: i don't think hrw means the hyperv driver,
17:09:28 mriedem stephenfin: i think he means libvirt running with hyperv,
17:09:30 mriedem like libvirt+xen
17:09:56 stephenfin I didn't even know that was an option :)
17:10:01 hrw I used 'hyperv on aarch64' as hypotetical impossible option
17:10:22 hrw or rather 'so far impossible' as MS already has windows 10 on aarch64
17:10:41 idlemind sean-k-mooney ya i have both of those things; in addition i had to do virsh edit for the instance after it's built and add the feature require for svm
17:10:53 mriedem stephenfin: https://libvirt.org/hvsupport.html
17:10:57 stephenfin hrw: Indeed. Never rule it out :)
17:11:23 stephenfin hrw: Alright, I'm mostly convinced and therefore drop my objections. Thanks for working through that with me
17:11:24 sean-k-mooney idlemind: with cpu-mode host-passthough all cpu flags from the host should be available in the guest
17:11:35 hrw stephenfin: thanks
17:11:46 mriedem this is what i was looking for https://libvirt.org/drivers.html#hypervisor
17:11:47 idlemind sean-k-mooney the catch is likely that i'm using amd where most ppl use intel (because of the dc hardware being almost exclusively intel these days)
17:11:58 stephenfin mriedem: Those libvirt guys have too much time on their hands
17:12:36 sean-k-mooney idlemind: that seams like a libvirt/qemu bug to me. it should work on amd or any other processor not just x86
17:12:38 hrw stephenfin: I like that fact - easier to use same tools despite hypervisor differences
17:12:38 idlemind sean-k-mooney would that be a bug in centos (my base kvm node for openstack) or in nova if all the cpu instructions aren't getting passed into the guest
17:12:50 mriedem yeah so guest.os_mach_type is per image,
17:12:55 mriedem so doesn't belong in _do_quality_warnings
17:13:16 stephenfin mriedem: Yup, just replied. The warning would have to go in that same area of the code
17:13:17 mriedem otherwise based on the host arch
17:13:20 sean-k-mooney idlemind: i think a centos/libvirt/qemu/kvm bug
17:13:52 idlemind sean-k-mooney k thx i can start there; any chance you know which metadata property you were thinking of to add the force for me as a work-around?
17:13:52 sean-k-mooney idlemind: how did you enable nested virt in kvm? what module arg did you set it is different on amd vs intel
17:14:47 mriedem wow even danpb was reviewing this patch
17:14:54 idlemind sean-k-mooney for centos in /etc/modprobe.d/kvm.conf they have the necessary lines for amd and intel you just uncomment the one you need. you can then reload the kvm_amd (in my case) module or reboot the host. i did reboots on both my hosts.
17:15:50 bkero- echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm.conf # or kvm_amd if you have it, then... modprobe -r kvm_intel; modprobe kvm_intel
17:15:50 idlemind sean-k-mooney i set nova.conf overrides to set cpu_mode = passthrough via openstack ansible i did not do anything with cpu_model
17:16:22 sean-k-mooney idlemind: ah its not passthrough its host-passthrough i belive
17:17:02 sean-k-mooney idlemind: yes it should be "host-passthrough"
17:17:09 hrw mriedem, stephenfin: replied
17:17:09 sean-k-mooney see https://docs.openstack.org/nova/queens/configuration/config.html
17:17:13 idlemind i think that's what i use because that comes through fine
17:17:36 hrw mriedem: I asked libvirt guys to take a look to make sure that I got the idea properly
17:18:14 hrw mriedem: as we were discussing (on irc) few ways of handling it and only this one turned out to be proper working without any random glitches
17:18:38 openstackgerrit Matt Riedemann proposed openstack/nova master: Rename the 'recreate' param in rebuild_instance to 'evacuate' https://review.openstack.org/508190
17:19:02 cdent well that's not confusing at all

Earlier   Later