| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 00:38:09 | sean-k-mooney | dcapone2004: im using cpu_mode=host-passthough | |
| 00:38:22 | sean-k-mooney | so its adding all of my virutalisable cpu flags by default | |
| 00:38:57 | sean-k-mooney | dcapone2004: can you check if you have os_type=windows in the image metadata | |
| 00:39:12 | sean-k-mooney | dcapone2004: if not that might fix it | |
| 00:39:27 | dcapone2004 | yeah, I'm using custom as we have some different CPUs in our clusters so i use custom to use the lowest common CPU model among them all | |
| 00:39:55 | dcapone2004 | I then use flavor traits to expose higher CPU models to VMs when needed based on the flavor | |
| 00:40:28 | dcapone2004 | aka, AVX2 to expose Haswell and have the scheduler route the VM to a node that has Haswell or better CPUs | |
| 00:40:30 | sean-k-mooney | traits wont make the cpu feature avaiable just so you are aware | |
| 00:40:53 | sean-k-mooney | i assume you are using the recently added support to list multiple cpu models | |
| 00:40:59 | dcapone2004 | correct | |
| 00:41:09 | sean-k-mooney | ya that should work | |
| 00:41:46 | dcapone2004 | I am assuming that it at least passes through the features that are included in cpu_map.xml definitions of each cpu, just none of the "extra traits" unless explicitly defined | |
| 00:42:31 | sean-k-mooney | custom will enable everytin in cpu_map yes | |
| 00:42:36 | dcapone2004 | the VMs recognize the CPU as Haswell vs IvyBridge when booted when I use the flavor when I define AVX2 as required | |
| 00:42:50 | dcapone2004 | ok, that is the behavior I thought I was receiving | |
| 00:43:08 | sean-k-mooney | yes we have logic to select the cpu model form the list that includes the feature you requested | |
| 00:43:20 | sean-k-mooney | we test them in order i belive and use the first that has all requested features | |
| 00:43:37 | dcapone2004 | correct that is the behavior I see and expected | |
| 00:43:57 | sean-k-mooney | well that was the behavior we intended but that does not mean we dont have a bug :) | |
| 00:44:04 | sean-k-mooney | nice to know it works | |
| 00:44:09 | sean-k-mooney | so in your case | |
| 00:44:22 | sean-k-mooney | i think we need to extend this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5390-L5392 | |
| 00:44:24 | dcapone2004 | only this hypervisor option I can't seem to figure out if it possible and I've been combing through the docs for 2 days now...I usually prefer to solve my issues myself before asking because every time I read docs for one thing I'm trying to fix, I end up learning 4 more things :-) | |
| 00:44:32 | sean-k-mooney | to add hypervior=off | |
| 00:45:14 | sean-k-mooney | dcapone2004: i may have missed it but did you check if you have os-type=windows in the image | |
| 00:45:41 | sean-k-mooney | so that https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5384-L5386 runs | |
| 00:45:48 | dcapone2004 | let me double check, pretty sure our windows images have a bunch of options set according to the docs recommendations but let me verify | |
| 00:46:59 | dcapone2004 | oddly enough i don't....we have os_distro set to win2k19 which is what i think was in the docs | |
| 00:47:19 | dcapone2004 | let me try adding that additional property and see what happens | |
| 00:49:25 | dcapone2004 | so in Horizon, os_type shows up under the XenAPI Driver Options....I think that is why we did not set it | |
| 00:49:38 | dcapone2004 | as I/we thought it was a Xen specific property | |
| 00:49:48 | sean-k-mooney | that code was added to trick nvidia dirvers into tinking it its runing on a physical host | |
| 00:50:00 | sean-k-mooney | hopefully it will help | |
| 00:50:08 | sean-k-mooney | on the horizon front | |
| 00:50:18 | sean-k-mooney | that is actully managed via glance metadefs | |
| 00:50:22 | dcapone2004 | am I looking at the correct property .... yes in my search for documentation, I read the "bug" report and the full history on that implementation :-) | |
| 00:50:27 | sean-k-mooney | so those should likely be updated | |
| 00:51:19 | dcapone2004 | but it is the correct property that I am looking to enable even though it appears to be documented a bit poorly in horizon? | |
| 00:54:02 | dcapone2004 | if (virt_type in ("qemu", "kvm") and | |
| 00:54:26 | sean-k-mooney | no its this one https://github.com/openstack/glance/blob/45749c30c1c02375a85eb17be0ccd983c695953f/etc/metadefs/compute-libvirt-image.json#L97-L105 | |
| 00:54:28 | dcapone2004 | That code calls a different hyperV specific function based on this property so I am hoping it is a winner :-)... will let you know shortly | |
| 00:55:05 | dcapone2004 | yeah that option in horizon is listed under XenApi in Horizon for some reason | |
| 00:55:16 | sean-k-mooney | weird | |
| 00:55:44 | sean-k-mooney | ok well if it does not work feel free to file that as a bug and link to the code i pointed too and the article. | |
| 00:55:58 | sean-k-mooney | we shoudl be able to add hypervior=no if libvirt support it | |
| 00:56:06 | sean-k-mooney | which it shoudl | |
| 00:56:23 | sean-k-mooney | but i would hope its not required with the existing code | |
| 00:56:52 | dcapone2004 | ok...I feel confident it is going to work with os_type=windows....if it does it is more of a documentation bug in glance/horizon for that property | |
| 00:57:33 | dcapone2004 | this is what horizon says about the property...OS Type (os_type) | |
| 00:57:34 | dcapone2004 | and it limits the injected host name to less than 16 characters. | |
| 00:58:21 | sean-k-mooney | what i have a ussuri deployment too let me check that wrong | |
| 00:58:33 | dcapone2004 | makes it seem as though the property is very Xen specific....your code clearly shows it is used in libvirt as well | |
| 00:59:59 | sean-k-mooney | ya so its not under the libvirt driver options for image section and is in zen with differet text | |
| 01:00:44 | sean-k-mooney | oh https://github.com/openstack/glance/commit/e1fe3024bb2482853130fac0be87e6a6a44e610e | |
| 01:01:38 | dcapone2004 | :-) someone else already noticed it | |
| 01:01:44 | dcapone2004 | so I just booted the VM | |
| 01:02:55 | sean-k-mooney | dcapone2004: stephenfin fixed it when he deleted the xenapi driver | |
| 01:03:04 | sean-k-mooney | but that is part of wallaby | |
| 01:03:08 | sean-k-mooney | not ussuri | |
| 01:03:27 | sean-k-mooney | dcapone2004: you can fix that in your current deployment via the glance api | |
| 01:03:33 | dcapone2004 | didn't pass hypervisor=no, but it did pass a whole bunch of other hv options....might essentially resolve the same issue...will know in about 6 minutes when hyper-v finishes installing...I greatly appreciate your help | |
| 01:03:36 | sean-k-mooney | you can update the metadata defs via the api | |
| 01:03:56 | dcapone2004 | yeah i can just update our internal MOPs | |
| 01:04:28 | sean-k-mooney | dcapone2004: yep os_type is used to enable the hyperv enlightenments too which enable the hyperv optimisations | |
| 01:04:38 | sean-k-mooney | it should improve you guest performance | |
| 01:05:30 | dcapone2004 | admittedly I don't overly care about nested VM performance....we basically use nested VM mostly to lab out potential deployments for customers | |
| 01:05:40 | dcapone2004 | but good to know anyway | |
| 01:06:11 | sean-k-mooney | dcapone2004: well it will impre the first level vm performance too and it shoudl reduce power use when the vms are ideling | |
| 01:07:58 | dcapone2004 | ok, maybe slight miscommunication.....these are being deployed on KVM hosts....not Hyper-V hosts....don't know if that makes a different in the configuration....I point that out because I cannot understand how exposes hyper-v features to the VM would aid performance when running on KVM | |
| 01:08:31 | sean-k-mooney | that is what i was expecting hyperv on kvm | |
| 01:09:13 | sean-k-mooney | window has special kernel code for runing on hyperv and kvm support some of the hyperv feature | |
| 01:09:41 | sean-k-mooney | https://libvirt.org/formatdomain.html#hypervisor-features has a table ot the hyperv feature | |
| 01:09:42 | dcapone2004 | i see | |
| 01:10:03 | sean-k-mooney | although we dont support enabling most of them basically because no one has asked or done it | |
| 01:11:49 | dcapone2004 | unfortunately the bad news is that didn't seem to resolve this specific situation.... Im about to try this out on a non openstack standalone kvm system to see if hypervisor=off does anything for it | |
| 01:12:18 | sean-k-mooney | so you could manally edit the xml and add that | |
| 01:12:21 | dcapone2004 | but sinc eyou mentioned performance improvements....is there anyway to add those flags to already existing, deployed/modified VMs? | |
| 01:12:27 | sean-k-mooney | then use libvirt to restart the vm | |
| 01:12:32 | sean-k-mooney | not openstack | |
| 01:12:53 | sean-k-mooney | dcapone2004: no not without a db update | |
| 01:13:03 | dcapone2004 | might try that as well first | |
| 01:13:21 | dcapone2004 | that is what I thought...db update and hard reboot? | |
| 01:13:32 | sean-k-mooney | if you were willing to do that then all you need to do is add img_os_type windows to each vm in the instance_system_metadata table | |
| 01:13:50 | sean-k-mooney | dcapone2004: yes db update and hard reboot | |
| 01:14:46 | dcapone2004 | alright, you have been very helpful, I am going to play around with a few things and see what happens, if the hypervisor=no option works, I might be asking for a feature request :-) | |
| 01:15:21 | sean-k-mooney | if you confim that adding the elemnt fixes the issue then we can simple add it here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5386 or here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5393 | |
| 01:15:23 | sean-k-mooney | as a bug fix | |
| 01:15:35 | sean-k-mooney | depending on if its jut for hyperv or for hyperv and kvm | |
| 01:15:56 | sean-k-mooney | sorry windows or windows and linux | |
| 01:16:17 | dcapone2004 | I think this is KVM specific based on the articles about the problem and how to fix it....I unfortunately don't have any openstack hyper-v nodes to test for sure | |
| 01:16:18 | sean-k-mooney | kvm/hyperv does not matter in this case | |
| 01:16:35 | dcapone2004 | linux nested virtualization works without issue | |
| 01:16:39 | sean-k-mooney | yep | |
| 01:16:47 | dcapone2004 | I've used it on this same cluster and with the same flavor without issue | |
| 01:16:49 | sean-k-mooney | i use it every day | |
| 01:17:08 | sean-k-mooney | i do all my openstack dev on my home openstack cluster | |
| 01:17:14 | sean-k-mooney | with nested virt and hypervior hiding | |
| 01:19:54 | dcapone2004 | 1 more question...to potentially save me some time searching....do you know where the xml files for VMs is in a kolla containerized deployment? | |
| 01:20:13 | sean-k-mooney | oh you dont edit the xmls | |
| 01:20:19 | sean-k-mooney | i use kolla | |