Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-03
17:57:55 sean-k-mooney live migrate almost works we just dont update the bridge name correctly im hoping to backport that
17:58:27 spatel nice! if that work
17:58:49 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add scatter-gather-single-cell utility https://review.openstack.org/594947
17:58:50 openstackgerrit Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785
17:58:50 openstackgerrit Surya Seetharaman proposed openstack/nova master: Modify get_by_cell_and_project() to get_not_qfd_by_cell_and_project() https://review.openstack.org/607663
17:58:52 sean-k-mooney spatel: haha i think im working on all your missing features :) https://review.openstack.org/#/c/605116/
17:59:14 openstackgerrit Merged openstack/nova stable/pike: nova-manage - fix online_data_migrations counts https://review.openstack.org/605840
17:59:25 spatel :)
17:59:51 spatel i have lots of requirement :) these are just starting
18:00:02 spatel sean-k-mooney: thanks for help!!!
18:00:02 sean-k-mooney my main focus this realease at least initally is livemigraton hardenign. e.g fixing edgecase like lb->ovs or sriov
18:00:25 nicolasbock <freenode_sea "nicolasbock: if you are still ar"> Thanks for the tip!
18:00:26 spatel i didn't know freenode will be very helpful.. last 2 days i am chasing google
18:01:12 spatel what you use to deploy your openstack? I am using openstack-ansible
18:01:14 sean-k-mooney spatel: no worries. im usually hear so feel free to ping me if you have issues
18:01:44 spatel I am going to spend next 6 month here :) until my cloud is ready!!
18:01:53 sean-k-mooney spatel: for developement devstack. i used to use kolla-ansible but recently joined redhat so i proably shoudl suggest OSP
18:02:07 spatel we spent million dollar last year in AWS so my boss want to build own AWS :)
18:02:39 sean-k-mooney spatel: that is how alot of compaines end up running opnestack clouds yes
18:02:56 spatel indeed
18:03:04 spatel OSP using tripleO right?
18:03:12 spatel i tried and found very complicated
18:03:23 sean-k-mooney yes that is the officaly supprot installer from redhat
18:03:30 sean-k-mooney spatel: and yes it can be
18:03:42 mnaser does anyone know if daniel berrange hangs out on irc much?
18:03:54 mnaser i'm looking at this old abandoned review and i'm wondering if this is still an issue -- https://review.openstack.org/#/c/241401/
18:04:14 sean-k-mooney mnaser: not on this irc but he is usally on the libvirt one
18:04:29 mnaser i'll try to ping him there
18:04:38 spatel sean-k-mooney: going to eat something, will catch you again, if any issue :) thanks again
18:06:49 sean-k-mooney mnaser: i think that is a bug that has been forgoten about but not nessacarily fixed
18:07:14 mnaser sean-k-mooney: yeah, it's not fixed, but it's been a while so i'm wondering if the whole "it doesnt working with backing" argument is no longer valid
18:07:40 mnaser we're setting up some really fast hardware (pci-e nvme drives) and want to squeeze the best performance out of it.. short of going to something like lvm
18:07:58 sean-k-mooney mdbooth: and lyarwood would like be able to comment better then i on https://bugs.launchpad.net/nova/+bug/1510328
18:07:58 openstack Launchpad bug 1510328 in OpenStack Compute (nova) "Nova pre-allocation of qcow2 is flawed" [Low,Confirmed]
18:08:15 openstackgerrit Jack Ding proposed openstack/nova master: Add HPET timer support for x86 guests https://review.openstack.org/605902
18:08:48 sean-k-mooney mnaser: right am in that case would you be better with a raw image instead of qcow if your always preallocating
18:09:57 mnaser sean-k-mooney: right, i'm thinking that might be the next path, raw files on disk
18:10:03 sean-k-mooney mnaser: if you are also supporting ceph or boot form volume raw can often be better too even if you are using more space for glance / image cache
18:10:03 mnaser but then we lose a lot of qcow2 features
18:10:27 sean-k-mooney mnaser: like live snapshot
18:10:36 mnaser yeah, a lot.. unfortunately
18:11:02 sean-k-mooney mnaser: i dont think anyone would object if you had a way to fix the bug but did not cause others
18:11:20 mnaser sean-k-mooney: yep.. its just that unfortunately there was no documentation as to why that was an issue with backing images
18:11:24 mnaser so thats what im trying to research
18:13:33 sean-k-mooney mnaser: its got to have something to do with the overlays that we create
18:13:50 mnaser yeah it looks like it's not really a possibility
18:13:51 mnaser :<
18:14:14 sean-k-mooney mnaser: mdbooth and kashyap should be able to confirm tomorow when they are back online
18:14:22 mnaser i'll wait to hear
18:14:40 mnaser now to find ways to benchmark this server
18:14:44 mnaser server/vm that is
18:15:23 mnaser http://paste.openstack.org/show/731425/
18:16:16 sean-k-mooney is that a vm with 468G of ram
18:16:34 sean-k-mooney sorry 472
18:17:00 sean-k-mooney i also like the insane amount of gpus
18:17:34 sean-k-mooney may i sugges you use it to play minecrat tootally how you should benchmark
18:17:46 sean-k-mooney mnaser: also i hear bitcoin is a thing :)
18:18:19 mnaser sean-k-mooney: aha, we're rolling out gpus and we have instances with 472G of ram, 48 (dedicated) threads, 1.8T of PCI-e NVMe storage..
18:18:33 sean-k-mooney mnaser: actully on a serious note you are an operator of a cloud with vgpus correct
18:18:51 mnaser sean-k-mooney: no vgpu support, only dedicated gpus (as far as we've planned)
18:19:17 mnaser part of this is MAYBE seeing if we can get some vGPU CI.. if possible, but i hear there are some more complicated reasons why its not possible
18:19:19 sean-k-mooney ah well does the lack of vgpu numa affinity effect your decision to use vgpus or deploy gpus in the cloud in general
18:19:46 sean-k-mooney mnaser: actully it might be useing complicated trick
18:20:36 sean-k-mooney e.g. nested virt + q35 chipset + viommu + pci passthoug of phyical gpu PF to host vm
18:20:58 mnaser i think we're starting to roll things out by having dedicated gpus to see market demand for it (we've had some). unfortunately the other thing that's coming to mind is i'm thinking that users who need gpu levels of performance probably would want 100% of it
18:21:25 mnaser we can make nested virt available for gpu instances so maybe thats possible
18:21:33 sean-k-mooney mnaser: have you talked to bauzas about possible vgpu ci?
18:21:57 mnaser sean-k-mooney: we briefly talked about it.. dansmith mentioned concerns about iommu and stuff that's beyond my level of comprehension :)
18:22:24 mnaser but we plan to provide at least 1 or 2 instances to openstack CI *if* there's a use case that makes sense
18:22:39 dansmith mnaser: he said viommu, so if that's a thing now then maybe it's doable
18:22:58 sean-k-mooney dansmith: yes it is but we have not enabled it in nova yet
18:23:06 sean-k-mooney but its trival so we could
18:23:42 sean-k-mooney well its a flavor extraspec + xml generation and other crap but its not technical very hard to do we just have not done it yet
18:24:15 mnaser i'd be more than happy to provide 1 or 2 instances with a gpu
18:25:07 sean-k-mooney dansmith: i was added in libvrt 2.1 and qemu 3.4 https://libvirt.org/formatdomain.html#elementsIommu
18:26:44 nicolasbock <freenode_mri "nicolasbock: you'll likely need "> I had to also update `instances.node` but then the allocation was updated correctly
18:26:51 sean-k-mooney mnaser: thats very generous. it would certenly help if we could actully test vgpu the upstream ci even if it was an experimtal job that did not run on all patches
18:27:42 mnaser while i wrap things up here i can push up a patch to add 1 or 2. we'll probably do it with min-servers: 0 and max-servers: 2 to start with
18:28:43 mriedem efried: i've replied in https://review.openstack.org/#/c/606122/
18:29:07 efried ack
18:29:40 spatel sean-k-mooney: currently i have "intel_iommu=on" in grub.conf, should i add "iommu=pt" too?
18:30:29 sean-k-mooney spatel: "iommu=pt" is not requried but advised
18:30:52 efried mriedem: +2
18:30:58 spatel will add that :)
18:30:58 sean-k-mooney spatel: this is my cmdline on my sriov systems BOOT_IMAGE=/vmlinuz-3.10.0-862.11.6.el7.x86_64 root=UUID=2cca5edf-cbcc-4f0d-91df-df438bbd56c5 ro crashkernel=auto rhgb quiet intel_iommu=on iommu=pt pci=assign-busses,realloc
18:31:19 spatel are you using SR-IOV?
18:31:25 spatel or DPDK?
18:31:37 mriedem efried: thanks
18:31:44 mriedem lazy-load can be a cruel mistress
18:31:49 sean-k-mooney spatel: pci=assign-busses,realloc is to work around some hardware bugs where my bios does not allocate enough iommu space
18:31:52 efried srsly
18:32:01 spatel nice!
18:32:08 sean-k-mooney spatel: iommu=pt is need for dpdk but not sriov
18:32:17 spatel oh! make sense
18:32:28 sean-k-mooney i enable it always so i can deploy both and swap between them
18:32:48 spatel sean-k-mooney: i have created new flavor (15 vCPU / 14G memory ) and i got this error
18:32:56 spatel ERROR (BadRequest): Instance CPUs and/or memory cannot be evenly distributed across instance NUMA nodes. Explicit assignment of CPUs and memory to nodes is required (HTTP 400) (Request-ID: req-400663e1-75d1-4bbc-a06b-07dcfd845be6)
18:33:19 spatel This is what i have in flavor hw:cpu_policy='dedicated', hw:numa_nodes='2'
18:33:54 sean-k-mooney spatel: yes the error could be improved. the vcpus needs to be devisable by the number of numa nodes othere wise you have to tell us how many cpus to put on each numa node
18:34:51 sean-k-mooney spatel: so i would jsut set it to 14 vcpus and 14G memory

Earlier   Later