| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 13:27:59 | dpawlik | I will change PS commit message soon | |
| 13:28:09 | mriedem | kashyap: are you aware of this kvm hidden feature thing? | |
| 13:28:10 | mriedem | ^ | |
| 13:28:17 | mdbooth | mriedem: I did :) I took a short cut to convincing myself that was correct. | |
| 13:28:33 | mriedem | mdbooth: at some point i should probably write that up in the devref, but... | |
| 13:28:39 | kashyap | I think I know what it means from the title | |
| 13:28:45 | openstackgerrit | Alex Szarka proposed openstack/nova master: Add method for verify multiple notifications https://review.openstack.org/465526 | |
| 13:29:01 | mdbooth | mriedem: Logically, that method makes no sense unless the volume is connected | |
| 13:29:02 | mriedem | dpawlik: kashyap: I don't know what "It allows to hide the KVM hypervisor signature on the guest. | |
| 13:29:02 | mriedem | This enables disabling of some paravirualization features in the | |
| 13:29:02 | mriedem | guest as well as allowing certain drivers which test for the | |
| 13:29:02 | mriedem | hypervisor to load." means | |
| 13:29:16 | mriedem | mdbooth: which one? get_config? | |
| 13:29:21 | mdbooth | Yeah | |
| 13:29:26 | mriedem | mdbooth: yeah it's super tightly coupled, | |
| 13:29:37 | mdbooth | If the connector hasn't connected it, we can't tell libvirt where it's connected | |
| 13:29:38 | kashyap | mriedem: Okay, I'm aware of what it is, it means: | |
| 13:29:39 | mriedem | we should almost just refactor to have connect_volume always return get_config... | |
| 13:29:46 | mriedem | but we have that live migration case | |
| 13:30:37 | kashyap | mriedem: It just lets one _hide_ the fact that it is a KVM guest | |
| 13:30:53 | kashyap | But removing the CPUID signature for guest that is running w/ KVM acceleration | |
| 13:31:12 | kashyap | dpawlik: Are you referring to the "-no-kvm" QEMU command-line option, right? | |
| 13:31:13 | mriedem | hide it from what? | |
| 13:31:37 | kashyap | mriedem: Hide it from whatever programs that depend on that output to identify: "Yes, this is a KVM guest" | |
| 13:31:59 | mriedem | alright | |
| 13:33:26 | kashyap | It is possible via the confusingly-named, QEMU command-line option '-cpu,kvm=off' | |
| 13:34:13 | kashyap | Which doesn't turn off KVM acceleration itself, merely the *signature* of it | |
| 13:34:28 | kashyap | You might wonder what exactly the **** is this "signature"? | |
| 13:34:29 | bauzas | cdent: FWIW, I'm not disagreeing with you on the long-term direction to see claims closer | |
| 13:34:39 | mriedem | cdent: so reading https://review.openstack.org/#/c/465171/3//COMMIT_MSG@30 i didn't realize that what ed is trying to do is make the nova-scheduler something that other projects are going to use | |
| 13:34:45 | mriedem | i.e. gantt 2.0 | |
| 13:34:54 | bauzas | cdent: I just think it needs to wait scheduler to be a library | |
| 13:34:57 | mriedem | we all agree that placement is generic and will be used by other projects | |
| 13:35:03 | cdent | bauzas: I've not felt like anyone is disagreeing, merely discussing | |
| 13:35:05 | kashyap | mriedem: The thing that exactly hides is this output that you normally see from the command `cpuid`: | |
| 13:35:17 | kashyap | $ cpuid | grep -i hypervisor_id | |
| 13:35:17 | kashyap | hypervisor_id = "KVMKVMKVM " | |
| 13:35:32 | mriedem | kashyap: that's within the guest? | |
| 13:35:36 | bauzas | cdent: but I do recall Jay and us being pretty clear on the fact that the scheduler code is not intended mid-term to be generic | |
| 13:35:36 | kashyap | mriedem: Yes | |
| 13:35:53 | cdent | mriedem: it's something ed said to me at some point in the conversation about "i don't think of the scheduler as 'nova'" and tickled my brain enough to write down explicitly | |
| 13:35:54 | bauzas | cdent: the idea is that placement is cross-project but scheduler is a nova-ism | |
| 13:36:09 | bauzas | (to reuse ed's wording) | |
| 13:36:21 | dpawlik | kashyap: yes (answer for your first question) | |
| 13:36:37 | cdent | bauzas: that may be the idea, but it may be that we don't want to build in things that make it hard to change our minds | |
| 13:36:38 | bauzas | so we could ship the scheduler code into a python module only used by conductors like I said in my reply | |
| 13:36:45 | kashyap | dpawlik: Are you depending exactly on the precise "-no-kvm" option? | |
| 13:37:05 | kashyap | dpawlik: If so, that is being considered for deprecation (in favor of "-cpu,kvm=off") | |
| 13:37:10 | bauzas | cdent: but for me, that sounds premature to discuss on your point, at least until we're fully down the path | |
| 13:37:25 | mriedem | bauzas: cdent: oh boy, ok, well, splitting nova-scheduler out or making it separate for other services to consume is not something i think most anyone besides maybe ed is thinking about | |
| 13:37:41 | bauzas | mriedem: yup, what I told to ed | |
| 13:37:50 | cdent | mriedem: not splitting out _now_, just ensuring it is not hard to do later | |
| 13:38:04 | bauzas | I think ed had that point | |
| 13:38:26 | bauzas | but I'm not seeing it strong enough to justify us to have scheduler doing allocations calls | |
| 13:38:33 | cdent | which means making the interface generic and not very nova-ish | |
| 13:38:36 | mriedem | has any other project even expressed interest in re-using nova-scheduler? | |
| 13:38:54 | bauzas | mriedem: in YVR, we had a session about gantt | |
| 13:39:00 | cdent | mriedem: I don't know, that's why I made my comment in the form of a question | |
| 13:39:02 | bauzas | mriedem: litterally nobody expressed interest in it | |
| 13:39:16 | bauzas | hence why we stepped back from that idea | |
| 13:39:31 | mriedem | well, and gantt was completely premature | |
| 13:39:34 | openstackgerrit | Pavel Gluschak (scsnow) proposed openstack/nova master: VStorage: changed default log path https://review.openstack.org/458557 | |
| 13:39:34 | bauzas | also, the BM/VM session told about that possible scope | |
| 13:39:37 | cdent | but also I think a lot of the lack of interest was based on a misunderstanding of what placement is going to be capable of | |
| 13:39:49 | openstackgerrit | Alex Szarka proposed openstack/nova master: Transform instance.exists notification https://review.openstack.org/403660 | |
| 13:39:50 | cdent | what placement can do it actually quite limited | |
| 13:40:05 | cdent | and any client of it is going to need to pick (somehow) from the results | |
| 13:40:08 | bauzas | and tbc, most of the people expressed usecases in multi-projects affinity, but noone stated the need for placing things other than instances (yet) | |
| 13:40:20 | bauzas | I made that question very explicit | |
| 13:40:37 | bauzas | and I all heard about affinity, not generic placement engine | |
| 13:41:32 | kashyap | mriedem: Will look the change, I see it is https://review.openstack.org/#/c/459753 | |
| 13:41:35 | bauzas | so, if you consider the approach step-wise, I think having the conductor workers responsible for doing the allocations is cool if we eventually end up with filter/weigher code owned by them | |
| 13:41:55 | mriedem | kashyap: yeah | |
| 13:42:15 | mriedem | kashyap: we're past any sort of spec freeze, but this doesn't require a spec, and is basic passthrough feature functionality via image meta | |
| 13:42:33 | mriedem | the description of the feature was just not clear to me | |
| 13:42:34 | kashyap | Yeah, libvirt has a simple XML mapping: | |
| 13:42:34 | kashyap | <kvm> | |
| 13:42:35 | kashyap | <hidden state='on'/> | |
| 13:42:35 | kashyap | </kvm> | |
| 13:42:45 | kashyap | mriedem: Yeah, hope the CPU ID example shows it | |
| 13:42:45 | mriedem | i see part of it was pulled from the original patch to add this to qemu | |
| 13:42:47 | mriedem | which was also confusing to me | |
| 13:43:03 | mriedem | so is the idea that someone won't know if they're talking to a vm or not? | |
| 13:43:04 | kashyap | mriedem: Yeah, it should be reworded and explained in context of Nova | |
| 13:43:06 | mriedem | b/c that's hidden? | |
| 13:43:35 | kashyap | mriedem: Yeah, I also wonderered, like you, first when I came across this: "What is the use case of this?" | |
| 13:44:24 | kashyap | Apparently, some proprietary nVIDIA drivers can be installed _if_ they don't see this 'hypervisor_id' option under `cpuid` | |
| 13:45:08 | kashyap | mriedem: This commit message that actually added the option in upstream QEMU will tell you the reason: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f522d2a | |
| 13:45:11 | dpawlik | kashyap: exactly | |
| 13:45:31 | kashyap | "The latest Nvidia driver (337.88) specifically checks for KVM as the | |
| 13:45:31 | kashyap | hypervisor and reports Code 43 for the driver in a Windows guest when | |
| 13:45:31 | kashyap | found. Removing or changing the KVM signature is sufficient for the | |
| 13:45:31 | kashyap | driver to load and work." | |
| 13:45:34 | dpawlik | kashyap: ack | |
| 13:46:04 | dpawlik | kashyap: should I also add the url for qemu git or its not necessary? | |
| 13:46:24 | kashyap | dpawlik: I'll respond on the review | |
| 13:48:31 | mriedem | why does the nvidia driver fail to load in that case? | |
| 13:48:36 | mriedem | isn't that a huge workaround? | |
| 13:49:25 | mriedem | so, you can get vgpus on this guest if you hide the fact that it's a guest? | |
| 13:49:36 | mriedem | but why does that nvidia driver care in the first place? | |