| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-05 | |||
| 11:45:02 | sean-k-mooney | EugenMayer: i hesitate to say this cause i dislike this code path but without cinder you can use masikari if you put the instnace state dir on an nfs share | |
| 11:45:04 | EugenMayer | sean-k-mooney understood. So it is more an API wrapper with high-level tasks, but it does not just act, that is for others to implement | |
| 11:45:17 | sean-k-mooney | EugenMayer: correct | |
| 11:45:25 | EugenMayer | sean-k-mooney nfs share is nothing else as cinder on horrible storage :) | |
| 11:45:59 | sean-k-mooney | yep and it used a diffeent code path then the one we normally use so less well tested | |
| 11:46:05 | sean-k-mooney | which is why its better to avoid it | |
| 11:46:15 | EugenMayer | right now, we go for local disks only, at least for the legacy VMs. K8s cluster is not yet decided. So most of the evacuate features / hot/live migration are not for us with the legacy vms | |
| 11:46:22 | sean-k-mooney | and the performance sucks vs a real shared stoage system | |
| 11:46:35 | sean-k-mooney | so back to your multi disk question | |
| 11:46:54 | EugenMayer | the performance is the main / only reason we are not jumping on ceph or similiar. We have to be realistic, our network is 1GB | |
| 11:46:54 | sean-k-mooney | you can create multi disk vms but its not how nova is typically used | |
| 11:47:08 | EugenMayer | with an MTU of 1400, no jumbo or anything | |
| 11:47:16 | sean-k-mooney | in the falvor there are 3 storage options disk, ephemeral and swap | |
| 11:47:32 | sean-k-mooney | disk is the root disk size | |
| 11:48:30 | EugenMayer | can i create VMs manually with any amount of disks since it's virsh in the end? I will only need this for the VMs i migrate - the ones i create from scratch are based on cloud-init and the proper disks you get using nova directly | |
| 11:48:32 | sean-k-mooney | ephemeral is the total amount of addtional ephemeral storage, i belive by default if you dont otherwise say all the ephemeral storage will be created as a singel addtional disk | |
| 11:48:52 | sean-k-mooney | you can however subdevide the ephemeral storage into multiple disk on the command line when you create the vm | |
| 11:49:15 | EugenMayer | using ephemeral storage we stopped, since the bug from 2016 that it cannot be resized :) | |
| 11:49:25 | sean-k-mooney | EugenMayer: no, as an end use you are not allowed to know the hypervior in use | |
| 11:49:29 | EugenMayer | nice, openstack server create is not the tool to go with here i guess | |
| 11:49:32 | sean-k-mooney | so you can just assume its virsh in the end | |
| 11:50:22 | EugenMayer | so using 'nova' is still hyperevisor agnostic, so it would be somewhat right? using virsh is discourage - that's what you mean, right? | |
| 11:51:40 | sean-k-mooney | openstack provides an abstration api over multiple hyperviors like libvirt/kvm, hyperv, vmware so yes the api is hypervior agnostic mostly | |
| 11:51:48 | sean-k-mooney | EugenMayer: using virsh is entirely unsupported | |
| 11:52:02 | sean-k-mooney | with opentask you can use virsh to inspect the xml for debugging | |
| 11:52:17 | EugenMayer | right now, i'am planing on how to migrate my old VMs which might have 1-3 disks. I know how to do it with one-disk setups. openstack image create --import .. the launch from snapshot. With multiple disks it all seems more complicated | |
| 11:52:22 | sean-k-mooney | but beyond that you shoudl never use virsh to modify any vm created by nova | |
| 11:53:00 | EugenMayer | i see, understood | |
| 11:53:03 | sean-k-mooney | with multi disk unfortunetly the only option that is supported via the api would be cinder | |
| 11:53:23 | EugenMayer | which is not an option (i understand, those would be volumes) | |
| 11:53:25 | sean-k-mooney | the unsupproted way woudl be to create a mulit disk vm. stop it and then copy the data | |
| 11:53:50 | EugenMayer | copy the data you mean, fs to fs? | |
| 11:53:56 | EugenMayer | or as an image | |
| 11:54:10 | sean-k-mooney | yes or via a rescue image but avoiding glance | |
| 11:54:55 | sean-k-mooney | so boot a 3 disk vm then put it in rescue mode using a clonzilla image and have clonzilla reimage the disk using the orignal vm as the image source | |
| 11:54:58 | sean-k-mooney | something like that | |
| 11:55:06 | EugenMayer | wow, that sounds quiet complicated. But understood. I somehow create and instance with x disks, then using grml and somehow mount new disks and old disks and sync the filesystem | |
| 11:56:05 | sean-k-mooney | there are some generic tools that might help virt2virt i think is one? i have never used them myself | |
| 11:56:21 | sean-k-mooney | https://libguestfs.org/virt-v2v.1.html | |
| 11:58:05 | EugenMayer | interesting, thanks | |
| 11:59:24 | EugenMayer | sean-k-mooney i assume that the disk if find on my compute is, eventhough named 'disk' nothing else then jsut a qcow disk | |
| 12:00:24 | EugenMayer | so i really consider going full force and trying to neither do nova-api nor virsh api, but replacing the disks. I understand this is not supported, but in the end, i do not run y types of hypevervisors and i need to migrate | |
| 12:00:42 | sean-k-mooney | yes you jsut need the qcow | |
| 12:01:05 | sean-k-mooney | ya an simple scp and overridign the disk might work | |
| 12:01:19 | sean-k-mooney | provided the disk dont have backing files | |
| 12:01:25 | EugenMayer | i will need to either adjust the size via the XML or via the API | |
| 12:01:32 | sean-k-mooney | you might need to first convert the qcow to a flatend one | |
| 12:01:50 | EugenMayer | yeah aware on how to do this, but i usually use flat | |
| 12:02:14 | EugenMayer | thank you a lot, again! | |
| 12:05:07 | EugenMayer | One last question, is there an API based way to activate nested-virtualization on a VM? I use host-passthrough already, but not sure that is enough. I need this to run an ESXi which i soley run for image disk conversion | |
| 12:05:41 | sean-k-mooney | no nested virt will be avaiable to the vm automatically if the host is configured to allow it | |
| 12:06:23 | sean-k-mooney | on older kernel you use to have to set teh nested virt flag in the intel-kvm or amd-kvm kernel module options | |
| 12:06:39 | sean-k-mooney | in newer kernels it default to enabled so that is no longer required | |
| 12:07:10 | sean-k-mooney | EugenMayer: you can check by installing linbvirt in the guest and runnign virt-host-validate | |
| 12:07:32 | sean-k-mooney | or just look for vmx or svm on the amd side in lscpu in the guest i think | |
| 12:08:54 | sean-k-mooney | so ya if your host is set up correctly then it shoudl just work | |
| 12:10:06 | sean-k-mooney | with that said my expeirnce with nested virt is mainly kvm on kvm and limited expericne with windows(docker/linux subsystem) usecases | |
| 12:10:27 | sean-k-mooney | both of those can be made work in openstack but have never tired esxi | |
| 12:17:39 | kashyap | EugenMayer: sean-k-mooney: Nested is enabled only in the newer _upstream_ kernels, though. | |
| 12:17:50 | kashyap | Some distributions might not enable it by default | |
| 12:18:05 | sean-k-mooney | well its enabled on rhel for intel by default now but not for amd | |
| 12:18:19 | kashyap | EugenMayer: So check before you run. A handy tool is `virt-host-validate` (it'll check for a whole bunch of things, including /dev/kvm) | |
| 12:18:23 | kashyap | You can run it on a VM too | |
| 12:18:54 | sean-k-mooney | yep also said that above its pretty handy but not well advertised in my experince | |
| 12:19:00 | kashyap | sean-k-mooney: No, not even for RHEL for Intel | |
| 12:19:15 | kashyap | sean-k-mooney: RHEL made it tech preview for AMD *and* Intel. | |
| 12:19:50 | kashyap | There it is, public docs: | |
| 12:19:51 | kashyap | https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_virtualization/creating-nested-virtual-machines_configuring-and-managing-virtualization | |
| 12:20:33 | kashyap | sean-k-mooney: Ah, I missed your virt-host-validate reference earlier; maybe we should include it in Nova docs somewhere too | |
| 12:20:51 | sean-k-mooney | well we retoactivly made it tech preview it was GA'd then we found issue on the intel support | |
| 12:21:36 | EugenMayer | thank you both - sorry was at dinner | |
| 12:21:59 | kashyap | Yes, I'm saying about the current status. "Retroactie" == well, if you spot blocker issues, then you must put it back to tech-preview | |
| 12:22:18 | kashyap | EugenMayer: No prob. In general, don't feel pressure to respond "instantly" on IRC | |
| 12:22:29 | kashyap | It's called "instant messaging"; not "instant responding" :D | |
| 12:23:36 | EugenMayer | if i get helped i tend to keep myself as 'instant responding' - but not anybody else. If find this somewhat respecting the time of the answer-giver (what ever that word is:) ) | |
| 12:24:09 | kashyap | Yes, sure. That's contextual | |
| 12:24:13 | EugenMayer | i currently run debian:bullseye with the stable kernel 5.10, will check what status it has and maybe upgrade to backports or spin up an compute on a different OS | |
| 12:24:42 | kashyap | EugenMayer: Some 7 years ago I wrote this thing, because we used to a see a lot of "naked pings" - https://www.rdoproject.org/contribute/irc-etiquette/ | |
| 12:25:01 | sean-k-mooney | EugenMayer: i think the change was made upstream after 5.10 in 5.14 so with 5.10 it might still be disabel by default | |
| 12:27:57 | EugenMayer | kashyap laters! | |
| 12:28:15 | EugenMayer | sean-k-mooney https://packages.debian.org/bullseye-backports/linux-image-amd64 so 5.14 could be it | |
| 13:39:14 | opendevreview | Lee Yarwood proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages https://review.opendev.org/c/openstack/nova/+/816738 | |
| 13:55:41 | opendevreview | Lee Yarwood proposed openstack/nova master: nova-next: Deploy noVNC from source instead of packages https://review.opendev.org/c/openstack/nova/+/816738 | |
| 16:07:45 | dansmith | gmann: if I have a policy rule with a specific scope_types= set, and then I override that rule with enforcer.set_rules({}) do you know what happens to the scope_types from the default? | |
| 16:08:26 | dansmith | it seems like they are being kept through the override (which I would expect), but that's preventing me from overriding some rules to @ in the tests, like check_image before check_image:allow_volume_backed | |
| 16:08:28 | dansmith | lbragstad: ^ | |
| 16:10:55 | opendevreview | Merged openstack/nova master: [Trival] Fix wrong microversion in TestClass name https://review.opendev.org/c/openstack/nova/+/816778 | |
| 16:13:19 | lbragstad | dansmith i think you're right in that it shouldn't override the scope_type | |
| 16:13:56 | dansmith | okay, so some of the tests we have hit two policies, and the tests try to @ the first one to make sure we test the second one, | |
| 16:14:15 | dansmith | but in the case of the "what happens when we enable scope checking" tests, I'm not sure how to get past that | |
| 16:14:28 | lbragstad | oh... | |
| 16:14:37 | dansmith | other than to just assume that scope violations get caught by the first one | |
| 16:15:19 | lbragstad | the only way i could think of doing that today would be re-register the rules so that you can reset the scope type of the one you want to pass through | |
| 16:15:26 | lbragstad | but that sounds clunky | |
| 16:15:42 | dansmith | yeah | |
| 16:16:11 | lbragstad | what's the scope_type for check_image, project? | |
| 16:16:14 | dansmith | or mock the enforce with a side_effect=[skip(), orig()] | |
| 16:16:48 | dansmith | it was both (of course, like all of them) but I'm moving it back to just project since it's on an instance | |
| 16:16:54 | dansmith | (and it's create_image, typo above) | |
| 16:17:32 | lbragstad | ah | |