| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 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 | hypervisor_id = "KVMKVMKVM " | |
| 13:35:17 | kashyap | $ cpuid | grep -i hypervisor_id | |
| 13:35:32 | mriedem | kashyap: that's within the guest? | |
| 13:35:36 | kashyap | mriedem: Yes | |
| 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: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 | bauzas | also, the BM/VM session told about that possible scope | |
| 13:39:34 | openstackgerrit | Pavel Gluschak (scsnow) proposed openstack/nova master: VStorage: changed default log path https://review.openstack.org/458557 | |
| 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 | <kvm> | |
| 13:42:34 | kashyap | Yeah, libvirt has a simple XML mapping: | |
| 13:42:35 | kashyap | </kvm> | |
| 13:42:35 | kashyap | <hidden state='on'/> | |
| 13:42:45 | mriedem | i see part of it was pulled from the original patch to add this to qemu | |
| 13:42:45 | kashyap | mriedem: Yeah, hope the CPU ID example shows it | |
| 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 | driver to load and work." | |
| 13:45:31 | kashyap | found. Removing or changing the KVM signature is sufficient for the | |
| 13:45:31 | kashyap | hypervisor and reports Code 43 for the driver in a Windows guest when | |
| 13:45:31 | kashyap | "The latest Nvidia driver (337.88) specifically checks for KVM as the | |
| 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? | |
| 13:50:34 | dpawlik | mriedem: its a good question for nvidia developers. Maybe one of the reason is bitcoin mining | |
| 13:50:50 | dansmith | mriedem: lots of software people have tried to limit running their stuff in a VM, supposedly for licensing reasons | |
| 13:51:21 | dansmith | it's not usually a very fruitful endeavor given that the hypervisor software is easy to change and the whole point of it is to _emulate_ something :) | |
| 13:51:22 | dpawlik | dansmith: +1 | |
| 13:51:52 | dansmith | kinda like most DRM.. annoying for everyone, but only buys you like 6 months of copy protection until people bust it up | |
| 13:55:32 | kashyap | mriedem: Let me ask Alex, the QEMU developer who wrote that commit | |
| 13:56:44 | mriedem | dpawlik: dansmith: kashyap: ok that makes more sense then, and was kind of what i'm looking for - the commit message and release note were just a bit cryptic | |
| 13:57:02 | mriedem | i wanted something in there about why we'd want to enable this feature, rather than that we just can so let's do it | |
| 13:57:55 | kashyap | mriedem: Yes, the commit message and the rel-note should definitely be improved | |
| 13:58:28 | dpawlik | kashyap, mriedem: working on it | |
| 14:00:27 | kashyap | Also, this should be called, 'kvm_hypervisor_id_hidden' -- maybe a tad too lengthy, but damn clear than "kvm_hidden", which will make people think: "Oh, this will disable KVM completely!" | |
| 14:00:39 | dansmith | I think it should not say kvm at all | |
| 14:01:07 | mriedem | hide_hypervisor_id | |
| 14:01:09 | mriedem | maybe | |
| 14:02:13 | kashyap | dansmith: It is hiding the KVM signature -- "KVMKVMKVM\0\0\0" | |
| 14:02:33 | dansmith | kashyap: sure but we don't want to end up with a xen_hide_id flag separate | |
| 14:02:39 | kashyap | I also say mentioning it useful because, there's upstream QEMU work to also add "TCG" disabling, too | |
| 14:04:39 | kashyap | dansmith: Yeah, I see what you mean, at Nova-level, you want a generic conf, that can handle different hypervisors (let they be KVM, TCG, Xen, etc) | |
| 14:04:49 | dansmith | yes | |
| 14:05:10 | kashyap | You're correct, mriedem's 'hide_hypervisor_id' sounds best to me | |