| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-18 | |||
| 10:23:04 | Spazmotic | You mean for the CPU mismatch? | |
| 10:23:04 | kashyap | mdbooth: Yes, live migration is a strict requirement | |
| 10:23:08 | mdbooth | Yeah | |
| 10:23:10 | kashyap | Yes, mismatch, indeed | |
| 10:23:13 | mdbooth | Spazmotic: Yeah | |
| 10:23:31 | kashyap | mdbooth: I still need to think more clearly about detecting it at guest start-up, where Nova generates the guest XML | |
| 10:23:41 | mdbooth | So if we could maintain host model strictly across live migrate, but reset it on restart... | |
| 10:23:41 | kashyap | What you're saying is --- | |
| 10:24:00 | mdbooth | s/guest/host/ startup | |
| 10:24:01 | kashyap | "If the guest is using a CPU without the PCID feature, add it." | |
| 10:24:22 | kashyap | (Assuming we detect that cleanly.) | |
| 10:26:32 | kashyap | mdbooth: So, from #virt, OFTC: | |
| 10:26:33 | kashyap | 11:21 < kashyap> Hi folks, can we detect at boot / start-up time what CPU model a guest is using? | |
| 10:26:36 | kashyap | 11:22 < kashyap> E.g. 'host-model' / 'host-passthrough' / or some custom model | |
| 10:26:39 | kashyap | 11:25 < danpb> in general you can't | |
| 10:26:41 | kashyap | 11:25 < danpb> you just get to see a model + flags in /proc/cpuinfo | |
| 10:27:58 | mdbooth | kashyap: I don't understand why we're interested in what the guest sees | |
| 10:28:17 | mdbooth | I mean, the guest is interested in what the guest sees, but we're just interested in what we present | |
| 10:28:36 | mdbooth | And we can absolutely determine that | |
| 10:30:11 | kashyap | mdbooth: Err, you're right. We should detect before the start-up | |
| 10:30:49 | mdbooth | kashyap: My thinking was that the host configuration for how guests are started is static, so we'd do it at host startup. | |
| 10:30:51 | kashyap | Using the baselineCPU() API | |
| 10:30:58 | kashyap | And VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES. | |
| 10:31:56 | mdbooth | Does that require a running domain? Or does it just query the xml file you referenced? | |
| 10:34:17 | kashyap | No, not a running domain | |
| 10:35:29 | kashyap | mdbooth: Near as I recall, libvirt caches the capabilities info it got from QEMU, via a QMP command. | |
| 10:35:48 | kashyap | (Before guest start up, obviously) | |
| 10:35:55 | kashyap | We'd be querying that cached XML, IIUC. | |
| 10:38:16 | Spazmotic | Checking my Xen boxes out of curiousity now | |
| 10:39:32 | kashyap | mdbooth: I'll stop hand-waving here, and get back with clearer details on the review. | |
| 10:39:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix openstackdocstheme options for api-ref https://review.openstack.org/534712 | |
| 10:39:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove crud from 'conf.py' https://review.openstack.org/534713 | |
| 10:40:55 | Spazmotic | Yeah interesting... i may need to send out an email to some peoples heh | |
| 10:41:47 | bauzas | gentle reminder for gibi and stephenfin about https://review.openstack.org/#/c/528832/ ;) | |
| 10:41:51 | lyarwood | kashyap: before you go, have you seen `Live Migration failure: invalid argument: monitor must not be NULL: libvirtError: invalid argument: monitor must not be NULL | |
| 10:42:05 | lyarwood | kashyap: urgh sorry, paste fail, ^ LM failure on f26 with the virt-preview repo | |
| 10:43:03 | kashyap | lyarwood: Got a link? | |
| 10:43:12 | lyarwood | ah wait that isn't the virt-preview repo | |
| 10:43:19 | lyarwood | kashyap: nope sorry local failure at the moment | |
| 10:44:29 | kashyap | Phew, okay. One less live migration issue to worry about, then | |
| 10:46:41 | lyarwood | cool, virt-preview works anyway | |
| 10:46:43 | lyarwood | sorry about that | |
| 10:51:30 | kashyap | No problem | |
| 11:02:37 | ameeda | jaypipes: good morning :) what If I use glance API to check the instance_metadata from nova side ? where is the wrong in that ? | |
| 11:04:27 | ameeda | jaypipes: I think that glance store image properties to nova db table "instance_metadata" | |
| 11:09:21 | mdbooth | kashyap: Reviewed, thanks. | |
| 11:09:52 | kashyap | mdbooth: Thank _you_ for spending time on this. I will read this on the train | |
| 11:14:58 | kashyap | mdbooth: A quick 'parser error', what do you mean by: "I don't think it lives [?] in this commit" | |
| 11:20:35 | kashyap | mdbooth: Disregard me, I got it. | |
| 11:34:30 | ameeda | jaypipes: I will update the patch with current functional test adding new comments. | |
| 11:35:45 | ameeda | jaypipes: I tried to access Nova DB directly, but I faced many issues. so I think the current scenario . | |
| 11:36:48 | ameeda | jaypipes: create new image with properties greater than 255 chars, then create server, great image from the created server, | |
| 11:37:30 | ameeda | jaypipes: new created image contains new image properties which is fetched from nova db. | |
| 11:38:04 | ameeda | jaypipes: then I check the image properties for new created image, so if it truncated it will raise error ] | |
| 11:40:41 | openstackgerrit | Ameed Ashour proposed openstack/nova master: change instance_system_metadata column type https://review.openstack.org/526900 | |
| 12:03:51 | bhujay | hello everybody , is there any config for niva so that multiple compute nodes can share a Fibre Channel Storage Array ? | |
| 12:09:11 | lyarwood | bhujay: for block storage? Nova would just use Cinder to provide volumes from the array and use os-brick to connect to these. | |
| 12:11:47 | bhujay | lyarwood: I am looking for VM to boot from the shared storage , just the way it does for rbd . This for ease of live migration | |
| 12:13:37 | lyarwood | bhujay: Yup, you can boot from volumes provided by cinder, the only imagebackend you could use for this would be LVM but IMHO using a cinder volume driver for the FC array is the way to go. | |
| 12:21:06 | bhujay | lyarwood: Just to make sure I got it correctly . Cinder to be configured for FC block storage , create bootable image volumes and while creating instance select that volume for boot. Right ? | |
| 12:26:16 | bhujay | lyarwood: But if we use boot from a image which is there in glance with glance backend as ceph will the instance OS ephemeral be placed on FC array by nova ? | |
| 12:28:06 | lyarwood | bhujay: yeah, create the volume from the image with `cinder create --image $UUID $SIZE ; cinder set-bootable $VOLUME_ID true` and then boot from it with `nova boot --boot-volume $VOLUME_ID [..] etc` | |
| 12:28:28 | lyarwood | bhujay: cinder copies the image into a volume with the above | |
| 12:28:44 | lyarwood | bhujay: but if you're already using rbd I don't see why you need the FC array :) | |
| 12:30:57 | openstackgerrit | Ameed Ashour proposed openstack/nova master: change instance_system_metadata column type https://review.openstack.org/526900 | |
| 12:31:58 | bhujay | lyarwood: Three reasons , one is urgent . I have run out of rbd space and i have huge capacity free from SAN , High performance for some load and in the long run I am going to have a multi network zone compute node with firewall so IP based storage will not work | |
| 12:37:24 | bhujay | lyarwood: Can you please see this link . what does this document mean https://docs.openstack.org/ocata/config-reference/compute/fibre-channel.html will it lead to nova placing the ephemeral volumes or boot from array directly without cinder ? | |
| 12:39:02 | openstackgerrit | Merged openstack/nova master: [placement] Fix resource provider delete https://review.openstack.org/529519 | |
| 12:54:04 | Spazmotic | If anyone has XenAPI Driver knowledge please feel free to take a look at https://review.openstack.org/#/c/533168/, would appreciate your review or words of advice. Will be AFK for a while but tag me and i'll get bakc to ya :) | |
| 12:55:30 | openstackgerrit | Merged openstack/os-vif master: Fix VF-rep lookup routine to use parent PF number https://review.openstack.org/531674 | |
| 13:03:07 | jaypipes | ameeda: good morning sir. I will look at your patch in a little bit. just note, however, your patch is lower on the priority queue than efried's patch series on resource provider trees, which I will be focusing on this morning. | |
| 13:03:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: [libvirt] Allow multiple volume attachments https://review.openstack.org/267587 | |
| 13:03:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Handle swapping to a multiattach volume https://review.openstack.org/532928 | |
| 13:03:38 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244 | |
| 13:03:38 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: [api] Allow multi-attach in compute api https://review.openstack.org/271047 | |
| 13:03:39 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add the nova-multiattach experimental queue job https://review.openstack.org/532689 | |
| 13:04:13 | lyarwood | bhujay: sorry, no, it doesn't | |
| 13:04:26 | ildikov | bauzas: thanks for reviewing the chain | |
| 13:04:56 | lyarwood | mdbooth: so I burned most of the morning getting a multi-node rbd ceph env created to test the migration flows | |
| 13:05:11 | lyarwood | mdbooth: if you had any cycles this afternoon and still wanted to take a look at the LUKS tests then please by all means do | |
| 13:05:12 | ildikov | bauzas: I had to rebase it, so I lost the +A on the bottom two patches | |
| 13:05:44 | mdbooth | lyarwood: Ok, will do. Won't be for a couple of hours, though. | |
| 13:06:25 | bhujay | lyarwood: Thanks for all the clarifications , this will save me a lot of time . I will follow your suggestion to use it through cinder | |
| 13:12:08 | bauzas | ildikov: ack, will look again | |
| 13:13:16 | bauzas | ildikov: +Wd | |
| 13:13:22 | bauzas | looking at the 3rd in the series | |
| 13:13:36 | ildikov | bauzas: thank you!!! | |
| 13:14:27 | efried | jaypipes Is there a plan in the future to implement any kind of allocation healing/discovery, whereby we try to validate allocations in the placement db against the VMs nova actually has deployed? | |
| 13:14:58 | jaypipes | efried: no plan, no | |
| 13:15:03 | efried | thx | |
| 13:15:16 | bauzas | efried: WDYM ? | |
| 13:15:19 | bauzas | self-healing ? | |
| 13:15:36 | bauzas | that should be done by computes, nope ? | |
| 13:15:40 | efried | bauzas Yeah, basically anything to make sure the placement DB is in fact in sync with what's going on IRL | |
| 13:15:42 | efried | bauzas No | |
| 13:15:55 | efried | bauzas The computes get to report info to sync the *inventory* | |
| 13:16:00 | efried | bauzas Not the *allocations* | |
| 13:16:19 | bauzas | efried: but the compute nodes know if the instances are good or not | |
| 13:16:52 | efried | bauzas But other than e.g. removing allocations for destroyed instances, they don't sync up the placement DB. | |
| 13:17:05 | efried | bauzas If what you're saying is that the two "should" never get out of sync... | |