Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-02
16:40:16 bauzas and ping me on IRC once you have the Launchpad BP up so I can approve it
16:40:29 gibi OK
16:40:37 gibi is there anything else for today?
16:40:43 yuriys no idea what that means, but sounds good?
16:41:03 yuriys ill just coordinate through dan i suppose
16:41:16 gibi yuriys: you need a file a blueprint here https://blueprints.launchpad.net/nova/
16:41:33 gibi so we can track the work
16:41:41 dansmith yuriys: with just an overview of what we said, no big deal
16:41:46 gibi yepp
16:42:08 yuriys Ah sounds good. Dang, I thought I was going to have like do a whole speech and everything
16:42:14 yuriys just to win over votes
16:42:15 yuriys haha
16:42:18 gibi :)
16:42:26 dansmith yuriys: I told you it wouldn't be a big deal :)
16:42:44 gibi it is not a bid deal if dansmith is on your side ;)
16:42:45 yuriys yeah, i think the expandability still needs to be part of that doc btw
16:42:50 yuriys for dollar reasons
16:43:00 yuriys but ill throw up a BP and we'll go from there
16:43:11 gibi cool
16:43:28 gibi is there anything else for today? I don't see other topics on the agenda
16:44:12 gibi it seems not
16:44:19 gibi so then I have the noble job to close the meeting:)
16:44:29 gibi thank you all for joining today
16:44:40 gibi #endmeeting
16:44:40 opendevmeet Meeting ended Tue Nov 2 16:44:40 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:44:40 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.html
16:44:40 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.txt
16:44:40 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-02-16.00.log.html
16:46:14 EugenMayer sean-k-mooney[m] what is the 'qemu' version. i guess nova-compute-qemu/stable 2:22.0.1-2 all is just management version of nova, not the actual qemu version
16:46:57 sean-k-mooney[m] try qemu-system-x86_64 —verions
16:47:18 EugenMayer sean-k-mooney[m] hmm, i use kolla, thus i guess libvirt is insite the docker package
16:47:52 sean-k-mooney[m] ah in that case you can docker exec into the nova_libvirt container
16:48:13 sean-k-mooney[m] it contians the libvirt and qemu binaries that are uesd
16:48:34 EugenMayer but that means that this is not controlled by me
16:49:11 sean-k-mooney[m] well you could rebuild the container. do you have multiple servers with differnt cpus?
16:49:11 EugenMayer sean-k-mooney[m] qemu-kvm 1:4.2-3ubuntu6.18 amd64 QEMU Full virtualization on x86 hardware
16:49:35 EugenMayer all main computes have the same (exact) - all have AMDs (there are smaller AMDs)
16:50:00 sean-k-mooney[m] if they are all exactly the same then there is no downside to using host-passthough
16:50:40 EugenMayer well i willh ave no live migrations
16:50:40 sean-k-mooney[m] it will give you the best performance but the limitation it imposes is you can only live migrate to other hosts with the exact same cpu
16:50:56 EugenMayer i have no live migrations since no shared block storage
16:51:11 EugenMayer (not planing to)
16:51:14 sean-k-mooney[m] you do not need shared storage for live migration
16:51:24 sean-k-mooney[m] it just makes it faster if you do
16:51:25 EugenMayer i guess a non-live migration from AMD-A to AMD-B should be no issue right
16:52:01 EugenMayer It tells me 'live migration is not available'
16:52:07 sean-k-mooney[m] cold migration has no cpu requirement beyond dont change the architeture i guess
16:52:37 sean-k-mooney[m] so ya you can always fall back to cold migration
16:52:42 EugenMayer sure, amd64 they all are, but most are the big ryzen, the others the little brothers
16:53:26 sean-k-mooney[m] so your other option is to find the closest cpu model that your qemu support and add in addtional cpu flags
16:53:34 EugenMayer 99% of live migration will happen between the main compute, all AMD Ryzen 9 5950X
16:54:02 sean-k-mooney[m] you could group them in an az
16:54:02 EugenMayer doesnt host-passthrough also harm the security / encapsulation?
16:54:30 EugenMayer yes, az planned for the big ones, the smaller ones are internal CI servers only (azure agents or concourse CI workers)
16:56:33 sean-k-mooney[m] no it just allows the vm to use all the cpu features
16:56:56 sean-k-mooney[m] host-model still allows the vm to know what model of cpu is used
16:57:08 EugenMayer hmm, all VMs are our VMs, no customers or such. so i know what runs on each of them
16:57:10 sean-k-mooney[m] so form a security point of view more or less the same
16:57:50 EugenMayer i guess passthrough and hosting freebsd could be an issue. What about running windows?
16:59:13 EugenMayer Thank you so much!
17:00:11 EugenMayer the only thing i disklike is that i would need to fix every compute and i'am not sure this configuration file is controlled by kolla, but they have overrides and in the end, i have chef, so this will do it in any case
17:01:31 sean-k-mooney[m] it is
17:02:11 sean-k-mooney[m] you can drop an override in /etc/kolla/config/nova.conf or in /etc/kolla/nova/nova-compute.conf i belvie
17:03:39 sean-k-mooney[m] https://docs.openstack.org/kolla-ansible/latest/admin/deployment-philosophy.html#kolla-s-solution-to-customization
17:03:53 sean-k-mooney[m] its basically the example they use
17:04:37 sean-k-mooney[m] its one of the reasons i like kolla
17:04:44 sean-k-mooney[m] it makes this type of config simple
17:04:48 yuriys there are way too many reasons to like kolla
17:24:26 EugenMayer sean-k-mooney[m] thanks. Did that with globa_pysical_mtu already
17:24:38 EugenMayer yuriys there also some to not do so. As with everything
17:33:42 EugenMayer sean-k-mooney[m] your right, nova.conf would work https://gist.github.com/EugenMayer/d74ffdc0b15db9c9c1af344bd27accd1
17:49:45 Zer0Byte hey @lyarwood are you there?
17:52:14 lyarwood \o evening, yeah
17:52:20 Zer0Byte hey
17:52:43 Zer0Byte https://bugs.launchpad.net/bugs/1949224
17:52:47 Zer0Byte is regarding about this bug
17:53:17 lyarwood Yeah apologies I just saw your update
17:53:28 lyarwood and I missed this QoS spec on the cinder side was per GB
17:53:47 Zer0Byte what i mean is performing the resize only should update the iops on the kvm configuration isn't it?
17:53:49 lyarwood I guess this is valid in that case but I'm not sure how we can fix this between Nova and Cinder
17:54:35 lyarwood if it's a size related QoS spec then yeah I guess it should
17:54:41 lyarwood tbh I didn't even know these existed
17:54:59 Zer0Byte yeah im using on my backend storage and work well
17:55:13 Zer0Byte the problem is with nfs this is why in moving to the frontend
17:56:23 Zer0Byte and if i create a new instance with the same volume resized take the new iops specs
17:56:29 lyarwood https://github.com/openstack/nova/blob/82be4652e2c840bd69ec354fd734a2d3f83f395b/nova/virt/libvirt/volume/volume.py#L63-L77 is where Nova is told about the cinder side QoS FWIW
17:57:53 Zer0Byte but this is only during volume attach ?
17:58:20 lyarwood Yeah there's a missing piece during a resize
17:58:36 lyarwood A workaround would be shelve and unshelve the instance
17:58:46 Zer0Byte let me try it
17:58:48 lyarwood That should regenerate the connection_info in cinder and have that passed to Nova
18:04:57 Zer0Byte you are right @lyarwood works if i perform shelve and unshelve
18:05:19 Zer0Byte quesiton but shelveand unshelve change mac address or any machine configuration?
18:05:59 Zer0Byte like uuid or serial
18:06:22 lyarwood Overall things should remain the same but I'm not entirely sure if we persist the MAC addresses, sean-k-mooney ^ any idea?
18:07:05 Zer0Byte yeah is running cloud init again
18:07:09 Zer0Byte changing the ssh key
18:08:48 lyarwood cloud-init shouldn't regenerate ssh keys if they already exist right?
18:09:05 Zer0Byte mhmm if the machine id change
18:09:10 Zer0Byte trigger execute cloud init agai

Earlier   Later