Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-09-20
13:15:48 bauzas what we could do is to test the OSC7.1.2 release without the CI
13:15:56 bauzas I think gibi did it
13:16:01 bauzas with my change
13:16:12 sean-k-mooney i also tested it with ci https://review.opendev.org/c/openstack/nova/+/929758
13:16:24 bauzas cool
13:16:26 sean-k-mooney it works for the limited usage we have in our gate
13:16:45 stephenfin Yeah, I think we're good to go now so
13:16:50 stephenfin Will pick that up Monday
13:16:54 sean-k-mooney bauzas: i have a seperate dnm that alows us to test any change to osc before its merged
13:17:05 bauzas ++
13:17:31 bauzas tbh, now we have RC1, I'm fine with using OSC7.x for 2025.1
13:17:32 sean-k-mooney if we jsut add a depends on agaisnt osc to https://review.opendev.org/c/openstack/nova/+/929757
13:17:47 sean-k-mooney we can test any patch
13:18:39 sean-k-mooney the requiremetns repo is alwasy used for source in the devstack jobs
13:19:14 sean-k-mooney meaning we can always tests any requirement bump after a release is done and beofre uc is updated
13:19:56 bauzas good with me
13:41:20 opendevreview Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968
13:44:55 opendevreview Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968
14:54:30 opendevreview Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968
14:55:04 opendevreview Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968
14:57:45 opendevreview Matthew Heler proposed openstack/nova stable/2023.1: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929969
15:33:57 haleyb bauzas: do you mind if i push an update for https://review.opendev.org/c/openstack/nova/+/916089 to fix the merge conflicts? have seen this downstream now
17:25:17 opendevreview Takashi Natsume proposed openstack/nova master: Update contributor guide for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova/+/929918
17:25:20 opendevreview Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858
17:27:13 opendevreview Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858
#openstack-nova - 2024-09-22
03:08:27 opendevreview OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/929719
08:35:16 opendevreview Takashi Natsume proposed openstack/python-novaclient master: Remove WebOb < 1.6.0 Code https://review.opendev.org/c/openstack/python-novaclient/+/930165
#openstack-nova - 2024-09-23
08:04:17 bauzas haleyb: sure, shoot
09:05:23 parasitid hi all, i have a question regarding the shelving process. would it be possible to "suspend" then shelve an instance, and unshelve + resume so that i can resume my instance on another host without restarting the OS ? Currently it seems that unshelving an instance reboots the VM and that its state file is lost during the shelving process. Am i correct ? thanks a lot
09:17:44 pas-ha[m] parasitid: I don't think 'shelving' saves a memory dump.. it only saves a disk state. Shelving is literally 'shutdown and create an image', and shelve-offload is '..and de-allocate resources' (removes local disk files, removes allocations in placement but keeps the instance in the DB).
09:18:18 pas-ha[m] And 'unshelving' just means 'rebuild the instance from the image we saved in the shelve command'
09:22:20 parasitid pas-ha[m]: ok thanks that's what i thought. I hoped that the state machine would differentiate an instance active state > shelved state and "instance suspended state" > shelved state. it could be nice to offload the instance state file if suspended so that unshelving an instance could restore its states
09:22:36 bauzas parasitid: you need to live-migrate your instance if you want to keep the instance alive
09:22:59 bauzas shelve means "stop my instance and put it in the shelve" :)
09:24:15 parasitid bauzas: well my usecase is : start a instance, use it. shelve it so i'm potentially not billed by the cloud provider. unshelve it and recover previous working environment
09:24:52 pas-ha[m] I don't think nova has anything similar to libvirt/virt-manager 'save VM' which is kind of like hibernate - dump a memory to a file, and resume from that (and disk) later.
09:25:16 bauzas snapshot it
09:25:23 pas-ha[m] that's what would be required for your use case as you want to save the memory as well
09:25:52 bauzas you could also suspend the VM
09:26:12 bauzas but your cloud provider will probably continue to bill you
09:26:45 parasitid bauzas: yes, but suspending a VM keeps the resources allocated, so you're often billed by the cloud provider. whereas shelving it frees the resources
09:27:01 bauzas sure, but that's why you need to stop the instance, right?
09:27:54 bauzas when you shelve, IIUC, you'll get a memory snapshot
09:28:36 bauzas sorry, a disk snapshot I mean
09:28:45 bauzas but the memory will be lost
09:30:08 parasitid bauzas: ok. couldn't the shelve process consider the VM state and also backup/restore the memory state file if ever the instance was in suspended state ?
09:32:02 bauzas I see your usecase tbc
09:32:42 bauzas but the problem here is that for the moment, AFAIK nova isn't able to save the memory
09:32:49 parasitid bauzas: usecase would be VDI/remote desktop
09:32:54 bauzas yup, I got it
09:33:18 bauzas that's in general *why* people want to save the memory :D
09:34:49 bauzas honestly, I don't know what to tell you, except that it would need a new feature
09:34:49 parasitid bauzas: are you sure ? i made a test this morning. when i suspend an instance and resume it, i can ssh back into my instance and tmux attach to my session and recover the vim buffer right where is was before suspending
09:35:20 bauzas suspend works indeed with the memory, but we don't snapshot it
09:35:31 bauzas that's why I said above "snapshot it"
09:35:39 parasitid bauzas: ok thanks. i understand perfectly. i jumped here just in case there would be a secret tip to achieve this :)
09:35:47 bauzas but your usecase is different : you want to /persist/ it
09:36:07 bauzas tbh, VMware supports that AFAIKK
09:36:18 bauzas (memory snapshot)
09:36:34 bauzas but as I said here, we need some new feature and some new API support for it
09:36:36 bauzas sean-k-mooney: ^
09:38:30 bauzas (that and live-resize are possibly the most needed features we'd like to have for VMware migration :) )
09:39:40 bauzas sean-k-mooney: I wonder, could we help parasitid with file-backed memory?
09:41:08 bauzas (oh I forgot, sean is on PTO this week)
09:43:31 sean-k-mooney[m] we have talked about this in the past, libvirt can do memory snapshots but we can because we do not guarantee a stable hardware interface
09:44:36 sean-k-mooney[m] when you unshleve you might shelve to a differnt host with differnent cpu, the pci device order in the guest may or may not be the same and if you have any sriov device there memory would not be captured
09:46:32 sean-k-mooney[m] we may be able to make it work in some cases but we would have to save and store the memory as an addtional image and also might need to recored other info about the guest like the pci device ids instead of allowing libvirt to choose them
09:47:08 sean-k-mooney[m] but no file backed memory will not help here. libivrt has a call to take a snapshot and include the guest memory
09:47:17 sean-k-mooney[m] so its not that we cant do that
09:48:55 gibi yeah shelve with memory would be like: hibernate your guest, write the image to disk, bring the image to another hardwared, and try to resume from hibernation. As far as I know if I change my hardware while my machine is hibernated and I try to resume I very well be in kernel panic territory
09:49:09 sean-k-mooney[m] for instances with no passthough devices like neurton sriov ports, or vgpus that use cpu_mode=custom and a pinned cpu model it proably would work
09:50:16 gibi wondering what restiction libvirt puts on resuming from memory snapshot while the hypervisor is reconfigured inbetween
09:50:37 sean-k-mooney[m] yep, so if there there was a strong demand for this, we could consider it but its very non cloudy, but it is an enterpirse virt feature
09:51:57 gibi If I have to choose what to spend time on between live-resize vs shelve with memory, then the former feels a more generally useful feature
09:52:28 gibi (and both is hard)
09:53:07 sean-k-mooney[m] the former is more cloudy
09:53:37 sean-k-mooney[m] shelve with memory is definetly in the enterpise virt space
09:56:24 bauzas_ I agree with the fact there are some technical constraints and limitations
09:56:54 sean-k-mooney[m] anyway yes im on pto this week so totally not going back to working on my home lab.
09:56:57 gibi it is more like we don't seem to know the list of constraints, and coming up with one is not simple
09:57:05 bauzas_ but the usecase written as "as a VDI user, I'd like my instance to be shelved with its memory so I can spin again my instance without problems" sounds a valid cloud usecase for me
09:57:18 gibi sean-k-mooney[m]: enjoy your PTO
09:57:22 sean-k-mooney[m] VDI its selef is iffy
09:58:04 gibi bauzas_: in a cloud we run cattle.
09:58:14 sean-k-mooney[m] im open to looking at this again but to be clear we have said no to this exact usecase once before and snapshot with memory once also
09:58:33 sean-k-mooney[m] shevle with memory i think is actully more reasonable then generic snapshot with memory
09:58:34 bauzas_ if you prefer, someone running a instance with virtual desktop capabilities
09:59:13 bauzas or there could be other workloads where saving the memory would be more than just nice
09:59:39 bauzas but there are security implications for sure, we'd need to keep the memory safe
09:59:49 gibi bauzas: I still reject the idea that this is cloudy. In a cloud you should be ready to loose a single VM any time.
09:59:52 sean-k-mooney[m] yep you just need to reconsile the fact that we provide no abi stablity for the guest.
10:00:10 sean-k-mooney[m] meaning if you add 2 volumes and remove 1
10:00:23 bauzas gibi: well, that ship has already sailed for a while :(
10:00:36 gibi sean-k-mooney[m]: yeah we can promise that we restore your memory but we cannot promise the guest kernel wont panic
10:00:46 sean-k-mooney[m] the first one, then the next time we generte the xml the remaining voluems pci adress will change
10:01:04 bauzas while I'm one of the most feroceous guys that say 'sorry, cloud', I tend to admit that /some/ workloads require more care
10:01:07 gibi bauzas: we can try to stop on that slippery slope :)
10:02:08 sean-k-mooney[m] we can add this to the list of things people want but i would port vtpm live migration higher personally
10:02:13 bauzas gibi: and ask the foundation to remove the Vmware migration to OpenStack whitebook ? :)
10:02:27 gibi unshelve with memory is like a brain transplant while you expect not just the patient to survive but also to keep all its past memories.

Earlier   Later