| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-02 | |||
| 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 | FYI, I'm vouching for this patch: https://review.opendev.org/c/openstack/nova/+/938215 | |
| 13:10:05 | zigo | It fixed https://launchpad.net/bugs/2085709 for us in production ! | |
| 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: Add managed flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/937649 | |
| 15:09:26 | opendevreview | ribaudr proposed openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | |
| 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 | 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:49 | bauzas | without using such aggs | |
| 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 | |
| 13:43:44 | sean-k-mooney | but we can see what others think | |
| 13:45:04 | sean-k-mooney | since we already have the instnaces in memory in the hoststate object for the affinty/anti affinity fileter this should not require any addtional db lookup so i expect teh perfoamce impact to be pretty minimal | |
| 13:45:35 | sean-k-mooney | and if the multipleer defaults to 0 there is no upgrade impact | |
| 13:45:58 | sean-k-mooney | so im leaning towards specless | |
| 13:46:22 | bauzas | sean-k-mooney: that's a good question, that's why I provided the bp, but we need to discuss this tomorrow indeed | |
| 13:48:00 | sean-k-mooney | i assume the algoitherim woudl be something like (count of common image properies in isntnace / count of total image propeies of exisiting instnaces) | |
| 13:48:33 | sean-k-mooney | that way the more image properies the current instnace as in common with the instance on a given host the more we prefer it | |
| 13:51:19 | sean-k-mooney | common/total will naturally pack or we can take 1 - (common/total) to spread by default | |
| 14:04:25 | sean-k-mooney | bauzas:i updated the whiteboard with my comments | |
| 14:06:31 | sean-k-mooney | bauzas: by the way the bill would not be huge if you spread window sinstance across all host | |
| 14:06:44 | sean-k-mooney | bauzas: microsoft only does host based liceineing on hyperv | |
| 14:07:35 | sean-k-mooney | for libvirt the volume lisenicing is not host base by vm based so packing or spreading has no impact in general on cost | |
| 14:09:18 | sean-k-mooney | the only way cost factors into this is is if you segreated your isntance today based on guest os then you may have under utilistation because fo the static partioning | |
| 14:10:51 | sean-k-mooney | which the weigher can avoid to some degree by allowing linux guests to use the slack space as you no longer need to staticly partion. in a normal libvirt deployment i would not recommend partioning host based on OS_TYPE any more really. there are some cases where it could make sense but in general no so much | |
| 14:11:15 | sean-k-mooney | the weigher is still reasonabel even with out the cost motive IMO | |
| 14:13:09 | aaron | thanks for the info sean-k-mooney - I did see your reply on the mailing list thread on this from 18 months ago. I can work around the qemu-kvm path using a symlink. I will do some testing with cold-migration rather than hacking qemu-kvm at this point | |