| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-12-30 | |||
| 07:56:48 | opendevreview | Takashi Natsume proposed openstack/python-novaclient master: Replace neutronclient with openstacksdk https://review.opendev.org/c/openstack/python-novaclient/+/932057 | |
| 10:03:31 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | |
| 10:03:31 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | |
| 10:03:32 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra spec for sound device. https://review.opendev.org/c/openstack/nova/+/926126 | |
| 10:03:32 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | |
| 10:03:33 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927354 | |
| 10:32:07 | opendevreview | Merged openstack/nova master: [tox] add LOCALE_ARCHIVE to passenv https://review.opendev.org/c/openstack/nova/+/929353 | |
| 12:07:14 | opendevreview | Jakub Darmach proposed openstack/nova master: Add context switch chance to other thread during get_available_resources https://review.opendev.org/c/openstack/nova/+/938215 | |
| #openstack-nova - 2024-12-31 | |||
| 02:45:59 | songwenping | hi team, does nova support create vm with special ipv4 and ipv6? | |
| 05:35:10 | songwenping | hi team, does nova support create vm with special ipv4 and ipv6? | |
| 08:36:00 | frickler | songwenping: not sure what you mean by "special", but a vm with both ipv4 and ipv6 is perfectly possible. though the details are likely more of a topic for neutron rather than nova | |
| 08:39:55 | songwenping | not special, appoint. sorry | |
| 08:40:58 | songwenping | i send an email to openstack-discuss@lists.openstack.org and attach the error message. | |
| 09:00:22 | frickler | oh, so this is about fixed ips, I see. no idea though, sorry | |
| #openstack-nova - 2025-01-02 | |||
| 07:12:56 | frickler | just noting this in case someone wants to followup with the submitter https://github.com/openstack/nova/pull/108 | |
| 11:30:10 | opendevreview | zhaixiaojuan proposed openstack/nova master: Add loongarch64 support https://review.opendev.org/c/openstack/nova/+/938355 | |
| 14:12:35 | opendevreview | Kaloyan Kotlarski proposed openstack/nova master: libvirt: Fetch the available vCPUs from the respective cgroup https://review.opendev.org/c/openstack/nova/+/927474 | |
| 14:43:18 | opendevreview | Kaloyan Kotlarski proposed openstack/nova master: Hardcode the use of iothreads for KVM. https://review.opendev.org/c/openstack/nova/+/918669 | |
| #openstack-nova - 2025-01-03 | |||
| 10:49:14 | opendevreview | Kaloyan Kotlarski proposed openstack/nova master: libvirt: Fetch the available vCPUs from the respective cgroup https://review.opendev.org/c/openstack/nova/+/927474 | |
| 13:10:05 | zigo | It fixed https://launchpad.net/bugs/2085709 for us in production ! | |
| 13:10:05 | zigo | FYI, I'm vouching for this patch: https://review.opendev.org/c/openstack/nova/+/938215 | |
| 13:48:48 | opendevreview | Kaloyan Kotlarski proposed openstack/nova master: libvirt: Fetch the available vCPUs from the respective cgroup https://review.opendev.org/c/openstack/nova/+/927474 | |
| 15:09:26 | opendevreview | ribaudr proposed openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | |
| 15:09:26 | opendevreview | ribaudr proposed openstack/nova master: Add managed flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/937649 | |
| 17:18:59 | opendevreview | ribaudr proposed openstack/nova-specs master: Migrate VFIO devices using kernel variant drivers https://review.opendev.org/c/openstack/nova-specs/+/937615 | |
| #openstack-nova - 2025-01-06 | |||
| 02:07:54 | opendevreview | Wenping Song proposed openstack/nova master: support create vm with ipv4 and ipv6 https://review.opendev.org/c/openstack/nova/+/938427 | |
| 05:44:26 | opendevreview | benlei proposed openstack/nova master: Abort live migration task when stop nova compute service https://review.opendev.org/c/openstack/nova/+/938223 | |
| 08:53:13 | nimesh_ | Encountered following error in nova logs while trying to attack cinder volume to a vm. Jan 06 12:52:09 root1-10 nova-compute[1281]: DEBUG os_brick.initiator.linuxfc [-] Could not get HBA channel and SCSI target ID, path: /sys/class/fc_transport/target8:*, reason: Unexpected error while running command. Jan 06 12:52:09 root1-10 nova-compute[1281]: Command: grep -Gil "500507681012b195" /sys/class/fc_transport/target8:*/port_name Jan 06 12:52:09 root1 | |
| 08:56:31 | harsh | Hello everyone. we are getting the above error in attaching a volume using cinder driver. Has anyone come across this in your environment? we have not made any changes in the switch config or backend config. Our OpenStack deployment is done using DevStack. | |
| 08:57:22 | sean-k-mooney | hum fiberchannel i suspect that is coming form os-brick rather then nova | |
| 08:57:45 | sean-k-mooney | nimesh_:^ | |
| 08:58:15 | sean-k-mooney | oh yes its in the message os_brick.initiator.linuxfc | |
| 09:00:16 | harsh | We can see that the host's WWPN : 500507681012b195 is present on the storage backend and when we try to attach a volume directly on the storage backend to this host, it works fine. But on openstack, it triggers the addvdiskhostmap and then immediately triggers rmvdiskhostmap to terminate the host attach. | |
| 09:00:37 | harsh | and so the volume goes from available to reserved and back to available. | |
| 09:02:02 | sean-k-mooney | the cider folks may be able to help more but it sound like the volume is not appearing on the host with the expect identifier | |
| 09:02:14 | sean-k-mooney | i.e 500507681012b195 | |
| 09:41:30 | nimesh_ | Thanks for the reference to os_brick.initiator.linuxfc | |
| 09:43:10 | sean-k-mooney | this could be a case where if you could just reboot the compute node it might fix itself. my guess is there is some invlaid state that is preventign the attachemnt fo the volume via the host fiberchannel adapter but i dont really have expecice with FC to say exactly how to detect/fix that | |
| 09:43:21 | sean-k-mooney | although i think a host reboot might resolve it | |
| 09:43:45 | sean-k-mooney | the cider folks have much more expirnce debugging that then we do | |
| 12:10:47 | aaron | Hey Nova folks. I’m trying to figure out how I can migrate a VM from a Centos 8 Stream system to an Ubuntu 22 host. Both running Yoga. The main issue I have right now is that the VM uses machine type 'pc-i440fx-rhel7.6.0' which isn't available on my Ubuntu host. Does anyone have any ideas on how I can work around this, or perhaps if I've missed any Nova tricks to get this working? I am trying to avoid recompiling qemu with the rhel m | |
| 13:13:04 | sean-k-mooney | aaron: unfortunetly the only way to do that is to cold migrate | |
| 13:13:30 | sean-k-mooney | that for two reasons 1 the machine type and 2 the qemu instnace path is diffent on centos vs ubunutu | |
| 13:13:40 | sean-k-mooney | so we cant live migrate but cold migrate will work | |
| 13:14:37 | sean-k-mooney | the fact its currently using the rhel specific pc machine type means that there is not operturnity to live migrate the instnace as that cannot be changed while the guest is running. | |
| 13:21:42 | sean-k-mooney | bauzas: this sound kind of like my boreign host weigher https://blueprints.launchpad.net/nova/+spec/image-metadata-props-weigher a weigher idea. not quite the same but similar. i wanted to select the most boring host based on traits rather then image properties. i also suggesstign adding image/flavor affinity weigher that would prefer packing/spreading instnace based on the | |
| 13:21:44 | sean-k-mooney | image/flavor they request and the instance already on a host in this case i guess you wanted to pack/spread isntance based on the image propeies on the current instance adn those requested by instances alredy ona host | |
| 13:25:45 | sean-k-mooney | we do have access to the instnace on a host already in the hoststate object | |
| 13:25:57 | bauzas | sean-k-mooney: not sure I understand what you say | |
| 13:26:00 | bauzas | sorry | |
| 13:26:22 | bauzas | sean-k-mooney: which host weigher are you explaining ? | |
| 13:27:12 | sean-k-mooney | so for hte last couple of release i have been debating adding 3 new weigher based on internal converstaion and customer bugs | |
| 13:27:44 | sean-k-mooney | the 3 i was condiering implemtiing were a image affinity weigher, flavor affinity weigher and boaring host weigher | |
| 13:27:54 | sean-k-mooney | the image propertiy weigher in https://blueprints.launchpad.net/nova/+spec/image-metadata-props-weigher | |
| 13:28:06 | sean-k-mooney | sounds like its similar to those in intent | |
| 13:28:46 | sean-k-mooney | i assume the intent is ot look at the image propertites in the current request and prefer or avoid host that have instnace with the same properites correct? | |
| 13:29:19 | bauzas | ah, ok | |
| 13:29:29 | sean-k-mooney | so rather then soft affinity/anti based on the flavor/image have soft affinity/antiaffinty based on the image properites | |
| 13:30:03 | sean-k-mooney | so you can pack/spread similar image in this case OS_TYPE=windows it the motivating example | |
| 13:30:15 | bauzas | yeah indeed, some *people* would want to be able to have Windows instances in some hosts | |
| 13:30:20 | bauzas | like, being packed | |
| 13:30:30 | sean-k-mooney | but without forcing it right | |
| 13:30:34 | bauzas | exactly | |
| 13:31:08 | bauzas | just because of the money you need to pass to Microsoft :) | |
| 13:31:09 | sean-k-mooney | and would this use host aggrate metadata or just the instnace on the host | |
| 13:31:34 | bauzas | I discussed about the aggregate with the *people* | |
| 13:32:00 | sean-k-mooney | ok the reason i asked that is i could see both as options but i think this would be the first aggrate aware weigher | |
| 13:32:09 | sean-k-mooney | its not actully a blocker either way | |
| 13:32:10 | bauzas | but the problem with aggregates is that you need to know *how many* hosts you will need to use per the aggregate (for example for Windows) | |
| 13:32:11 | sean-k-mooney | just wondering | |
| 13:32:31 | sean-k-mooney | ya so that why i was wondier if we woudl od this more organically | |
| 13:32:45 | sean-k-mooney | by looking at the instance already on a host rather then using aggreate metadata | |
| 13:32:51 | bauzas | of course, you can add a new host to an existing aggregate, but if you want to remove one host from an aggregate, then you need to move the instances | |
| 13:33:07 | sean-k-mooney | not nessiasrly | |
| 13:33:17 | bauzas | that's why they prefer to have a way to pack the windows instances | |
| 13:33:20 | sean-k-mooney | well ya kind of | |
| 13:33:31 | bauzas | without creating aggs | |
| 13:33:58 | sean-k-mooney | so i would be inclided ot do this without relying on aggreats | |
| 13:34:47 | sean-k-mooney | the image affiinity weigher i was condierding was a more restrctive version of that i.e. it would only look at the image uuid rather the the perperteis and try and pack/sptread based on that | |
| 13:35:31 | sean-k-mooney | if i was to implement https://blueprints.launchpad.net/nova/+spec/image-metadata-props-weigher i would not depend on host aggartes or provide two diffent implamtions | |
| 13:36:20 | sean-k-mooney | one that looked at the instnace already on the host and a second that would look at metadat on the hosts aggreates | |
| 13:37:09 | sean-k-mooney | but i think as an operator i woudl want this to work more or less automatically without requireing me to add aggreate metadata or a lot of config | |
| 13:37:16 | bauzas | exactly | |
| 13:37:36 | bauzas | that's what I wrote in the description | |
| 13:37:57 | sean-k-mooney | well the reason i started this converstaion is i did not find the descript partically clear | |
| 13:38:05 | bauzas | ha | |
| 13:38:27 | sean-k-mooney | i could read between the lines but if you wanted to ask for a specless blueprint tomorrwo i think you need a clearer description | |
| 13:38:34 | bauzas | well, I wrote the problem and I explained why aggregates can be used but why we need to create a new weigher | |
| 13:38:49 | bauzas | without using such aggs | |
| 13:38:49 | sean-k-mooney | so "That's why we would like to create a specific ImageMetadataPropsWeigher for looking at how many instances have a specific prop and then operators could use it for that case or for something else (like packing instances by machine types)" | |
| 13:38:52 | sean-k-mooney | the last line | |
| 13:38:58 | sean-k-mooney | is really want you want ot do right | |
| 13:39:11 | sean-k-mooney | it was not clear to me that you wanted to avoid aggreates | |
| 13:39:24 | bauzas | I can surely modify the description :) | |
| 13:40:41 | sean-k-mooney | if you can add someting explict like "This blueprint propsoes addign a new weigher that will pack/spread instance based on teh image properies requested by the instance and the image propeteis of existing instnace on indivugale hosts" | |
| 13:40:47 | sean-k-mooney | then i think it will be fine | |
| 13:42:06 | sean-k-mooney | the other comment i have is more na implemation detail but since all weigher are enabeld by default the multipler for this oen should likely be 0 to avoid any upgrade impact and then +/- can be used for spread/pack | |
| 13:43:07 | bauzas | sean-k-mooney: done :) | |
| 13:43:20 | sean-k-mooney | im in two minds about if this shoudl requrie a spec or not but i assuem we will discuss that in the team metting tomorow | |
| 13:43:39 | sean-k-mooney | i dont think its particallary contoverial | |