| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-30 | |||
| 09:18:19 | viks____ | https://www.irccloud.com/pastebin/6LLVRG5F/ | |
| 09:18:43 | viks____ | Why read speed in the vm is very less and why the write speed is high on vm compared to host? I use below commands to test read and write using sysbench: | |
| 09:18:50 | viks____ | https://www.irccloud.com/pastebin/bzcImC3H/ | |
| 09:19:00 | viks____ | Can someone tell me why i see the above behaviour. Also How do i get better performance for disk I/o? | |
| 09:32:12 | elod | lyarwood: thanks for working on the live-migration job issue! ... and sorry, I have some questions in the live-migration patch. o:) | |
| 09:33:41 | lyarwood | elod: np I'll look now | |
| 09:33:55 | lyarwood | viks____: can you provide any more context, which virt driver are you using, storage backend etc | |
| 09:35:14 | viks____ | KVM/libvert | |
| 09:35:55 | viks____ | also i use qemu images | |
| 09:36:04 | viks____ | sorry qcow2* | |
| 09:44:16 | kashyap | viks____: When benchmarking I/O patterns, this is a good post to refer to: http://blog.vmsplice.net/2017/11/common-disk-benchmarking-mistakes.html | |
| 09:46:05 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/victoria: zuul: Replace nova-live-migration with zuulv3 jobs https://review.opendev.org/c/openstack/nova/+/764432 | |
| 09:46:06 | lyarwood | elod: ^ updated, hopefully that's cleaner and easier to understand now. | |
| 09:47:10 | elod | lyarwood: looking | |
| 09:58:11 | elod | lyarwood: one more quetsion: so now nova-evacuate is merged into the live-migration job by calling 'run-evacuate-hook' role. so the 'nova-evacuate' playbook is not needed anymore. Did you leave that playbook (playbook/nova-evacuate/run.yaml) there in case someone wants to run it explicitly? | |
| 09:59:45 | lyarwood | elod: nope that's a mistake, I'll remove it from master now | |
| 10:00:23 | elod | lyarwood: oh, thanks! | |
| 10:01:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: nova-evacuate: Remove leftover playbook from standalone job https://review.opendev.org/c/openstack/nova/+/764618 | |
| 10:08:12 | viks____ | kashyap: Thanks.. in that post, fio is used. I'm using sysbench. also i'm trying to compare the results b/n host and vm using the same set of commands.. i think that should be fine.. or ?? | |
| 10:10:29 | kashyap | viks____: Same set as in with "sysbench"? | |
| 10:14:18 | viks____ | kashyap: i meant i am running the above commands in vm as well as the host running the vm and then comparing the results | |
| 10:14:43 | kashyap | viks____: As another case: also run on the host _without_ running the VM | |
| 10:14:55 | kashyap | viks____: Then you can compare and contrast further | |
| 10:16:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Move query param generation to RequestGroup o.vo https://review.opendev.org/c/openstack/nova/+/756894 | |
| 10:21:17 | viks____ | kashyap: .. The above is the result of that only.. first on the host without any vm.. then after creating the vm, running test within the vm.. and i was expecting some kind of similar results b/n them.. if u see above, read speed on host is too high compared to that in vm... and write speed is more in vm than that of host itself.. | |
| 10:21:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor _claim_pci_device_for_interface_attach to prepare for qos https://review.opendev.org/c/openstack/nova/+/756895 | |
| 10:23:25 | openstackgerrit | Merged openstack/nova master: Revert "zuul: Skip test_attach_scsi_disk_with_config_drive in nova-ceph-multistore" https://review.opendev.org/c/openstack/nova/+/764311 | |
| 10:23:47 | kashyap | viks____: Hmm, I don't have bright ideas; can you come over to #qemu on OFTC network? There are more Block Layer devs who have better ideas on these kind of perf issues | |
| 10:27:28 | kashyap | viks____: If you can't; I can ask for you in a bit. (I"m in the middle of something) | |
| 10:28:36 | viks____ | kashyap: is that related to both kvm and qemu? or just qemu? Because i'm using KVM... | |
| 10:29:07 | openstackgerrit | Adit Sarfaty proposed openstack/nova stable/train: Retry on vmware create_vm when it fails https://review.opendev.org/c/openstack/nova/+/764515 | |
| 10:30:08 | kashyap | viks____: It's for QEMU. But even if you're using KVM, QEMU is doing most of the heavy-lifting. All the I/O stuff is handled by QEMU's block layer. | |
| 10:30:38 | kashyap | viks____: QEMU is implicit in "KVM/libvirt" | |
| 10:30:52 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: Add regression test for bug #1899649 https://review.opendev.org/c/openstack/nova/+/764625 | |
| 10:30:52 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: compute: Don't detach volumes when RescheduledException raised without retry https://review.opendev.org/c/openstack/nova/+/764626 | |
| 10:30:53 | openstack | bug 1899649 in OpenStack Compute (nova) "Volume marked as available after a failure to build" [Undecided,In progress] https://launchpad.net/bugs/1899649 - Assigned to Lee Yarwood (lyarwood) | |
| 10:40:55 | kashyap | viks____: I have just asked your question to a QEMU dev on your "write perf better in guest than on host" question; I'll let you know if there's a response | |
| 10:41:30 | kashyap | (I asked the author of the earlier-mentioned benchmarking blog post.) | |
| 10:44:36 | viks____ | Ok.. thanks | |
| 10:48:59 | kashyap | viks____: So, here we go: | |
| 10:50:53 | kashyap | viks____: It's likely that the [host] page cache is being used, so host vs guest numbers could be wildly different to due different amounts of RAM. | |
| 10:51:09 | kashyap | viks____: So the first step is to check whether the benchmark is going through the page cache. If it does, then it's possible that the amount of physical disk I/O being done is quite different between guest and host, and therefore performance is also very different. | |
| 10:52:23 | kashyap | viks____: It's point-2 in the blog post abov ("Bypass the page cache"). You might want to re-test with 'fio' to compare and contrast. | |
| 10:54:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Remove KeyPair model from main DB https://review.opendev.org/c/openstack/nova/+/763989 | |
| 10:57:13 | stephenfin | lyarwood: Could you hit https://review.opendev.org/c/openstack/nova/+/749315/ https://review.opendev.org/c/openstack/nova/+/749312/ and https://review.opendev.org/c/openstack/nova/+/759114/ (remove XenAPI final bits)? | |
| 11:03:30 | viks____ | kashyap: ok.. thanks a lot.. will check with fio once | |
| 11:04:55 | lyarwood | stephenfin: ack sure | |
| 11:29:46 | lyarwood | stephenfin: https://review.opendev.org/c/openstack/nova/+/759114/ - As it isn't passing CI anyway can you remove `Remove` from the commit subject ;) | |
| 11:30:10 | stephenfin | um, yeah, fair /o\ | |
| 11:31:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Neuter 'BandwidthUsage', 'BandwidthUsageList' https://review.opendev.org/c/openstack/nova/+/759114 | |
| 11:31:59 | stephenfin | lyarwood: ^ | |
| 11:32:43 | lyarwood | ta | |
| 11:34:45 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Drop models for removed services, features https://review.opendev.org/c/openstack/nova/+/698706 | |
| 11:41:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: db: Remove KeyPair model from main DB https://review.opendev.org/c/openstack/nova/+/763989 | |
| 11:55:44 | stephenfin | gibi: I corrected the docstring as requested at https://review.opendev.org/c/openstack/nova/+/764376/ fwiw | |
| 12:00:18 | priteau | Hello. I have an affinity server group, with a single instance in it. The instance is shut off. I can't cold migrate this instance, ServerGroupAffinityFilter is removing all hosts. Is this a known issue? | |
| 12:01:11 | priteau | I found https://bugs.launchpad.net/nova/+bug/1890065 but I am not sure it's the same problem, since it is about 2 instances being live migrated | |
| 12:01:11 | openstack | Launchpad bug 1890065 in OpenStack Compute (nova) "Impossible to migrate affinity instances" [Wishlist,Opinion] | |
| 12:58:07 | gibi | stephenfin: ack, looks good | |
| 12:59:20 | gibi | priteau: I think it is the general behavior is known, if you have instances in an affinity group then you cannot migrate them. (the power state does not matter either). The edge case when you have only one instance in the affinity group is not handled spcially. Do you have a use case where you need a single instance in an affinity group? | |
| 13:06:21 | priteau | gibi: I've encountered this while migrating every instance on an OpenStack cloud during a c7 to c8 migration, I don't know why the user set it up that way. I suppose one use case would be to a server group for all instances of a cluster, which could potentially scale down to 1. | |
| 13:09:09 | gibi | priteau: solving the migration problem generally is hard, as that needs a way to say ignore-the-affinity-rule-for-this-migration which is most probably means an API impact. The single instance case could be solved by always ignoring the affinity rule, so that is easier but I don't know that solving only the single instance case would really help much | |
| 13:09:52 | priteau | Agreed. | |
| 13:10:26 | priteau | On the advice of johnthetubaguy I temporarily changed the policy in the instance_group_policy table and reverted it after the migration. | |
| 13:42:33 | openstackgerrit | Merged openstack/nova master: doc: Fix rendering in the PTL guide https://review.opendev.org/c/openstack/nova/+/764175 | |
| 13:56:38 | gibi | did anybody see pip error like "ERROR: Links are not allowed as constraints" I got hit by it recently in grenade https://39757d668f2e13d2ecb5-94a4d63114c603d5be2910eb980b9a2e.ssl.cf1.rackcdn.com/756894/3/check/grenade/fe26d2e/job-output.txt | |
| 14:02:31 | gibi | both grenade and grenade-multinode hits it | |
| 14:02:42 | gibi | this is from the same patch running the grenade-multinode https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_57e/756894/3/check/nova-grenade-multinode/57ea016/logs/grenade.sh.txt | |
| 14:12:27 | gibi | it seems it is started happening a lot in the last hour or so http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Links%20are%20not%20allowed%20as%20constraints%5C%22 | |
| 14:14:08 | jangutter | gibi: I was just about to start sending up signal flares! | |
| 14:14:21 | gibi | jangutter: thanks | |
| 14:14:45 | jangutter | gibi: happened to me too, I was working on stable/victoria and at first I thought I did something wrong. | |
| 14:17:31 | jangutter | best I can figure out: https://github.com/openstack/devstack/blob/master/inc/python#L386 <--- devstack has been using this method for ages now. I wonder if a pip update converted the warning to an error. | |
| 14:20:45 | gibi | yeah, that sound like a possibility | |
| 14:24:06 | jangutter | Removing that line (and the preceding backslash) seems to unblock it for me, but figuring out the consequences of that needs someone with a lot more experience on requirements, pip and the projects needs. | |
| 14:37:13 | gibi | hm, I cannot push to opendev gerrit now | |
| 14:37:24 | gibi | fatal: Unpack error, check server log | |
| 14:37:24 | gibi | error: remote unpack failed: error Missing tree 466cd024745bbeffebf3f8e598759fcc9b75df4d | |
| 14:47:19 | kashyap | stephenfin: gibi: I'm still to comb through some review comments on Secure Boot spec before the spec-review day tomm. Excuse my delay. | |
| 14:48:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM https://review.opendev.org/c/openstack/nova/+/764766 | |
| 14:52:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: Add regression test for bug #1899649 https://review.opendev.org/c/openstack/nova/+/764625 | |
| 14:52:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/ussuri: compute: Don't detach volumes when RescheduledException raised without retry https://review.opendev.org/c/openstack/nova/+/764626 | |
| 14:52:17 | openstack | bug 1899649 in OpenStack Compute (nova) "Volume marked as available after a failure to build" [Undecided,In progress] https://launchpad.net/bugs/1899649 - Assigned to Lee Yarwood (lyarwood) | |
| 14:52:40 | gibi | kashyap: no worries, Milestone 1 is this week but we only freeze specs at M2 | |
| 14:53:44 | kashyap | gibi: Ah, thank you. I didn't realize that spec-freeze is at M2. | |
| 14:54:40 | gibi | kashyap: M2 is spec freze M3 is feature freeze | |
| 14:55:06 | gibi | I guess in the past there was a time when we freezed specs at M1 but we don't do that in the last couple of cycles | |
| 14:55:20 | kashyap | I see | |
| 15:00:00 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Allow extending an existing instance allocation https://review.opendev.org/c/openstack/nova/+/757109 | |
| 15:00:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Make remove allocation symmetric with add allocation https://review.opendev.org/c/openstack/nova/+/757110 | |
| 15:12:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM https://review.opendev.org/c/openstack/nova/+/764771 | |
| 15:14:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM https://review.opendev.org/c/openstack/nova/+/764772 | |
| 15:16:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM https://review.opendev.org/c/openstack/nova/+/764773 | |
| 15:17:30 | gibi | (sorry for the noise) | |
| 15:18:18 | jangutter | gibi: still checking the pip thing? | |
| 15:18:32 | gibi | jangutter: nope, I got hit by a gerrit issue | |
| 15:36:33 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out port resource deallocation https://review.opendev.org/c/openstack/nova/+/757111 | |
| 15:42:39 | stephenfin | lyarwood: Don't know if I linked these already, but those changes to improve logging for PCI requests are here https://review.opendev.org/q/topic:%2522bug/1852727%2522+status:open | |
| 15:42:50 | stephenfin | If you care to cast an eye over them :) | |
| 15:43:31 | lyarwood | ack can do | |