Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-19
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
14:21:04 openstackgerrit Alex Szarka proposed openstack/nova master: Refactor create_delete_server_with_instance_update https://review.openstack.org/466296
14:22:35 kashyap mriedem: Thanks; that's useful
14:22:36 kashyap "(Integer) Maximum number of live migrations to run concurrently. This limit is enforced to avoid outbound live migrations overwhelming the host/network and causing failures. It is not recommended that you change this unless you are very sure that doing so is safe and stable in your environment."
14:22:37 openstackgerrit Alex Szarka proposed openstack/nova master: Add method for verify multiple notifications https://review.openstack.org/465526
14:40:26 dansmith woot

Earlier   Later