| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-02 | |||
| 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 | EugenMayer | sean-k-mooney[m] qemu-kvm 1:4.2-3ubuntu6.18 amd64 QEMU Full virtualization on x86 hardware | |
| 16:49:11 | sean-k-mooney[m] | well you could rebuild the container. do you have multiple servers with differnt cpus? | |
| 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 | 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:40 | EugenMayer | well i willh ave no live migrations | |
| 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 | EugenMayer | doesnt host-passthrough also harm the security / encapsulation? | |
| 16:54:02 | sean-k-mooney[m] | you could group them in an az | |
| 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 | |
| 18:09:11 | Zer0Byte | n | |
| 18:09:38 | Zer0Byte | and cloudinit perform ssh-keygen | |
| 18:10:56 | sean-k-mooney[m] | lyarwood: the mac adress comes from the neutron port so it wont change | |
| 18:11:06 | sean-k-mooney[m] | the machine id i guess you mean the one shown in dmidecoe | |
| 18:11:22 | sean-k-mooney[m] | i think that depends on your config but i think its the vms uuid by default | |
| 18:11:51 | sean-k-mooney[m] | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.sysinfo_serial | |
| 18:14:00 | sean-k-mooney[m] | Zer0Byte: so it would only change if you had set the sysinfo_serial to OS which uses the host /etc/machine-id file , hardware which uses the host uuid form libvirt or auto whcih choses between those | |
| 18:14:50 | sean-k-mooney[m] | Zer0Byte: so with our default config of unique unshleving should not change the guest serial and cloud-init should not run | |
| 18:15:23 | sean-k-mooney[m] | the mac adress should not change either unless you changed it manually in neutron while i was sheleved | |
| 18:17:11 | lyarwood | anyway there's some additional tooling in Xena to refresh connection_info for shutdown instances without the need to shelve and unshelve etc | |
| 18:17:32 | lyarwood | https://docs.openstack.org/nova/latest/cli/nova-manage.html#volume-attachment-commands | |
| 18:17:59 | lyarwood | that's another way to workaround it while we try to work something out in-tree | |
| 18:18:34 | lyarwood | tbh I can't think of a way with the current cinder APIs | |
| 18:19:13 | Zer0Byte | i got to go thanks anyway i will check the option of @sean-k-mooney[m] | |
| 18:20:26 | sean-k-mooney[m] | no worries im offically on pto until tomorrow anyway so not really here today just saw you question while i was checking over my car insurance | |
| 19:01:23 | EugenMayer | Anybody in here uses freezer (successfully?) | |
| 19:16:00 | dansmith | bauzas: when you return: https://blueprints.launchpad.net/nova/+spec/nova-change-default-overcommit-values | |
| 20:10:42 | hyang[m] | Can anyone help to take a look this patch https://review.opendev.org/c/openstack/nova/+/811521 thanks in advance! | |
| 22:31:55 | opendevreview | Merged openstack/nova stable/stein: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/813451 | |
| #openstack-nova - 2021-11-04 | |||
| 00:47:12 | opendevreview | Ghanshyam proposed openstack/nova stable/train: DNM: test tempest train-last tag https://review.opendev.org/c/openstack/nova/+/816598 | |
| 08:01:33 | gibi | good morning | |
| 08:03:10 | opendevreview | Balazs Gibizer proposed openstack/nova stable/victoria: Parse alias from domain hostdev https://review.opendev.org/c/openstack/nova/+/816486 | |
| 08:07:39 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Prevent leaked eventlets to send notifications https://review.opendev.org/c/openstack/nova/+/816487 | |
| 08:08:47 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Avoid unbound instance_uuid var during delete https://review.opendev.org/c/openstack/nova/+/816488 | |
| 08:09:33 | gibi | bauzas: the reno for the pps work has landed so you can marke the | |
| 08:09:39 | gibi | https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate | |
| 08:09:43 | gibi | bp as implemented | |
| 08:09:46 | gibi | \o/ | |
| 08:11:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748 | |