Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-24
16:46:40 sean-k-mooney simondodsley: so windwos clustering required the vm to be create with a volume configured to use type=lun which cant be set durign attach only vm creation
16:46:47 dansmith yep, was just going to say ^
16:47:01 sean-k-mooney we shoudl probaly fix that at some point
16:47:13 sean-k-mooney but anyway i am not sure if you can overried that with our libvirt section
16:47:17 dansmith is that enough to enable it? I thought not
16:47:25 sean-k-mooney we have a cofnig option for discard but i tought it was for nova provisioend storage
16:47:27 dansmith I thought lun was the only way
16:47:43 sean-k-mooney no i think you need lun for scsi v3
16:47:49 simondodsley so how do we set the type=lun at vm creation?
16:47:57 sean-k-mooney i just ment that even behond that im not sure if you can overried discard form nova
16:49:03 sean-k-mooney simondodsley: so the only discard cofnig im awre of in nova is https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_disk_discard which woudl turn it off for the host but that says "nova managed disks"
16:49:18 dansmith sean-k-mooney: I think if they want the guest to use discard and have that make it all the way to the actual physical device they need to use lun, no?
16:49:47 sean-k-mooney dansmith: well that what will happen if discard is enabeld on the cinder volume in the connection info
16:49:54 dansmith I thought libvirt discard would only hit the qemu storage driver, like ceph or qcow2
16:50:19 sean-k-mooney dansmith: i guess there are two diffent things happenign here
16:50:51 sean-k-mooney simondodsley made the assertion that truning of discard migh help with the scsi command making it to the backend. i think we both agree it not related to that
16:51:05 dansmith tight
16:51:11 dansmith *right :)
16:51:25 sean-k-mooney simondodsley: so if you look at the server create api https://docs.openstack.org/api-ref/compute/#create-server
16:52:10 sean-k-mooney there is an option device_type filed in the request
16:52:17 sean-k-mooney in the block device mappings
16:52:50 sean-k-mooney sorry that might not be the correct filed
16:53:03 sean-k-mooney i think you want block_device_mapping_v2.disk_bus i will neeed to check the other doc
16:53:25 sean-k-mooney https://docs.openstack.org/nova/latest/user/block-device-mapping.html
16:53:40 sean-k-mooney ok no so you want disk_bus=scsi and deivce_type=lun
16:54:02 sean-k-mooney """disk_bus and device_type - low level details that some hypervisors (currently only libvirt) may support. Some example disk_bus values can be: ide, usb, virtio, scsi, while device_type may be disk, cdrom, floppy, lun. This is not an exhaustive list as it depends on the virtualization driver, and may change as more support is added. Leaving these empty is the most common
16:54:04 sean-k-mooney thing to do."""
16:54:48 simondodsley ok - so how would that be forced from the comand line, or the gui?
16:55:01 sean-k-mooney you cant do it form horizon
16:55:12 sean-k-mooney from the cli you an do it when creating the block device mapppings
16:55:32 sean-k-mooney https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-create
16:55:54 sean-k-mooney you have to use teh --block-device parmater instead of --volume
16:55:59 simondodsley awesome - i see - thank you. We will give that a try
16:55:59 sean-k-mooney https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-create-block-device
16:57:46 sean-k-mooney simondodsley: when dan fixed this he added some tempest test that validate this is functional with lvm and multi attache. although obviosly not with a windows workload
16:58:02 sean-k-mooney simondodsley: but we do have coverage of creating a vme with a mutiatch volume in lun mode
16:58:42 sean-k-mooney https://github.com/openstack/tempest/blob/f4a8698b97a5433b8e64df408aace2fb14c2cb22/tempest/api/compute/volumes/test_attach_volume.py#L469
16:58:45 simondodsley and this will ensure that SCSI page 83 will be passed through correctly?
16:59:21 sean-k-mooney do you ahve a refence to that defintiion. it will ensure that scsiv3 command are aviable to the guest
16:59:29 sean-k-mooney without that you onlyhave access to v2 commands
17:02:37 sean-k-mooney simondodsley: by the way we only fixed this fucntionaly in recent version of nova
17:02:47 sean-k-mooney i think form dalmation on
17:03:02 simondodsley oh - so it won't work on caracal
17:03:34 simondodsley how did anyone every use windows clustering before this fix then?
17:03:37 sean-k-mooney i can check when we fixed it but no livbirt changed it api because qemu stop supproting the serial atibute with type lun a few years ago
17:03:58 sean-k-mooney windows supprot clustierning with other ways of doing synconisation
17:04:12 sean-k-mooney i.e. not file system absed it has 3-4 modes
17:04:27 sean-k-mooney so either they used one of the other mode or they didnt do it with libvirt
17:04:51 sean-k-mooney i.e. they were usihg hyperv or vmware or ironic
17:04:52 simondodsley this is the error from windows - `Physical disk {} does not have the inquiry data (SCSI page 83h VPD descriptor) that is required by failover clustering. Status: The request is not supported`
17:05:09 sean-k-mooney yep
17:05:18 dansmith that's what lun should fix
17:05:32 simondodsley but it only from dalmation...
17:05:47 sean-k-mooney or really old libvirt
17:05:52 dansmith simondodsley: also, clustered windows is not cloudy and openstack really focuses on cloudy workloads :)
17:06:08 simondodsley i know that, but tell customers :D
17:06:08 dansmith so that's why it's recent
17:06:12 dansmith just saying.
17:06:55 sean-k-mooney so the fix in dalmation was https://github.com/openstack/nova/commit/575ff86a4f1572786d66639f774405fbc074fdb1
17:07:07 sean-k-mooney which depend on another change that was done in caracal
17:07:28 sean-k-mooney it might be possibel to backport to caracal but not before
17:07:43 sean-k-mooney the prior change i dont think is backportable (using alias)
17:08:04 dansmith not backportable upstream, but doable for simondodsley you mean
17:08:49 sean-k-mooney well if it just needs https://github.com/openstack/nova/commit/575ff86a4f1572786d66639f774405fbc074fdb1 that might be ok upstream but the prior change to use the alias instead of serial to lookup the devices is much more invasive
17:08:54 sean-k-mooney but that already in caracal
17:09:35 simondodsley if we can backport the patch to caracal I can try and convince canonical to apply it downstream as well
17:10:49 sean-k-mooney simondodsley: its a serise of 3 patches https://review.opendev.org/q/topic:%22lun-device-serial%22
17:11:03 sean-k-mooney simondodsley: i would like to get elodilles input on if that is upstream backporable
17:18:15 sean-k-mooney simondodsley: strictly speaking https://bugs.launchpad.net/nova/+bug/2065084 was a latent bug for years so i think it could be backported upstram but it does not hurt to ask
17:19:03 sean-k-mooney the new feature that was added in caracal that it implcictly depend on is not backportable upstream really
17:19:26 simondodsley just so i haven't got this wrong... from Dalmation we can use `openstack server create --block-device disk_bus=scsi,disk_type=lun,volume_size=x,volume_type=whatever`
17:19:27 sean-k-mooney so if it was backproted it would only be to 2024.1
17:19:38 simondodsley i thin that backpor would be fine
17:19:59 sean-k-mooney yes taht looks correct to me
17:20:03 simondodsley cool
17:20:12 sean-k-mooney well you might need to set the destination type
17:20:32 sean-k-mooney destination_type=volume
17:20:55 sean-k-mooney you also need to set the source type
17:21:12 sean-k-mooney basically need to set all the filed for the block device mappings for that entry
17:22:03 dansmith sean-k-mooney: what's the justification for backport upstream? it's been broken forever, not sure it ever worked, not a regression in recent memory and thus seems entirely a feature to me
17:22:52 sean-k-mooney dansmith: just that it was tracked as a bug upstream as it worked in theory with old libvirt
17:23:02 sean-k-mooney but i agree that its not a very strong justification
17:23:23 sean-k-mooney that why im relucatnt to propose ti without impot form the stable team
17:23:35 sean-k-mooney e.g. elodilles or others
17:24:18 dansmith okay I thought you were implying it had a good justification.. to me it's just a feature.. if it ever worked it was long enough ago that it's not really a regression,
17:24:36 dansmith so even if it's fixing a bug that never worked, it's enabling a whole new workflow, behaviors, etc.. very feature-y to me
17:25:11 sean-k-mooney yep. canconcal can assesss if they want to fix it in there downstream indepenetely of if we think its upstream fixable too
17:25:14 simondodsley would it elp if a customer raised a bug report against this?
17:25:19 sean-k-mooney so simondodsley i would still reach out to them about it
17:25:32 sean-k-mooney simondodsley: not really we have downstream custoemr bugs relate to it too
17:25:51 sean-k-mooney although it never workined in our downstream that we can tell for any supproted release
17:26:24 sean-k-mooney i.e. its been broekn for many many years
17:26:32 simondodsley i get it
17:26:58 sean-k-mooney we are also debtatign if we can backprot this internally but we have not done that yet
17:27:39 sean-k-mooney our latest downstream product is based on antelope and it does tno have the otehr fature which is the harder oen to backprot safely
17:28:00 dansmith no, a customer bug report would not change my mind :)
17:28:33 sean-k-mooney for what its worth we totelly condier this to be a feature downstream
17:29:03 sean-k-mooney and honestly an incompelte one since you cant use it with attach
17:30:10 sean-k-mooney modifying the nova api to allow setting the device type to lun on attach will need a new microverison and someone to actully do the work :)
17:31:56 sean-k-mooney do be clear that woudl be nice ot have for other reason as it would allwo you to create a volume form an iso and attach it as a cd_rom

Earlier   Later