| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 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 | |
| 14:07:47 | sdague | or secret_agent_mode :) | |
| 14:08:40 | kashyap | sdague: Heh | |
| 14:09:02 | kashyap | sdague: You mean, enable_backdoor | |
| 14:10:41 | sfinucan | Morning, mriedem. Could you take a shot at [1] again today? https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:bp/move-nova-cmds-to-cliff | |
| 14:11:44 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 14:11:47 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387 | |
| 14:11:52 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082 | |
| 14:11:52 | mriedem | maybe | |
| 14:12:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 14:12:04 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021 | |
| 14:12:06 | openstack | Launchpad bug 1634668 in OpenStack Compute (nova) "Compute API Reference - version response doesn't require 'updated'" [Medium,Confirmed] | |
| 14:12:06 | mriedem | sdague: oomichi: mtreinish: i just noticed this bug again https://bugs.launchpad.net/nova/+bug/1634668 | |
| 14:12:19 | sfinucan | maybe will do | |
| 14:12:22 | mriedem | about how tempest checks that 'updated' is in the version response, and that test is part of defcore | |
| 14:12:38 | mriedem | would it be wrong to remove that from the tempest schema response validation? | |
| 14:13:58 | kashyap | mdbooth: mriedem: An unrelated question: When trying to migrate 50+ guests, will Nova attempt to do them all in parallel? | |
| 14:15:19 | mdbooth | kashyap: I know my script explicitly pipelined them. Don't recall any limiting in Nova. | |
| 14:15:38 | kashyap | mdbooth: Which script is this? | |
| 14:16:07 | openstackgerrit | Alex Szarka proposed openstack/nova master: Refactor create_delete_server_with_instance_update https://review.openstack.org/466296 | |
| 14:16:37 | mriedem | kashyap: live migration or cold migration, because for live migration https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L526 | |
| 14:17:44 | kashyap | Live migration | |
| 14:17:45 | mriedem | kashyap: by default live migrations are restricted to one at a time on a given compute | |
| 14:17:53 | mriedem | see the max_concurrent_live_migrations option | |
| 14:18:25 | mriedem | sdague: johnthetubaguy: dansmith: oh seers of nova lore, do you remember if boot from volume came before volume attach or after? | |
| 14:18:48 | dansmith | after I'm sure | |
| 14:18:56 | mriedem | that's what i assumed | |