Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-09-23
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.
10:02:28 sean-k-mooney[m] this is notthign to do with vmware
10:02:43 sean-k-mooney[m] we have a vmware direver and they never cared to enable this usecase
10:03:06 sean-k-mooney[m] we have disucss this in an inperson ptg before
10:03:11 sean-k-mooney[m] so this is an old request
10:03:17 gibi bauzas: just because the fundation say so brain transplant will not work out of the boz
10:03:18 bauzas doesn't vsphere support snapshoting the memory ?
10:03:20 gibi x
10:03:35 bauzas I like the idea of "brain transplant"
10:03:38 sean-k-mooney[m] it does but it does not do it as part of shelve
10:03:53 bauzas but this is more live neurolinks transplants
10:04:18 bauzas I can consider the brain as disk while the neurotransmitters are the RAM :)
10:04:29 sean-k-mooney[m] libvirt, hyperv and vmware all can do this (so can virtual box) but none of them ever enabled it in there virt driver
10:05:14 gibi the disk content goes through a full kernel boot process with hw probing etc, the resume from ram tries to continue exectuing where it left of without a boot process
10:06:35 bauzas then why shelve w/ memory would be more acceptable than snapshot w/ memory ?
10:06:45 bauzas shit
10:06:51 gibi I think we can ask the libvirt folks how do you feel about moving the libvirt memory snapshot, disk, and domain def to another compute and try to resume, if they say they support it then lets discuss further
10:07:24 bauzas sorry, I said "shit" because I was trying to understand exactly the diffs with suspend
10:08:19 bauzas gibi: again, I don't have the energy nor the will to push that more forward, I was just saying that the usecase may sound legit
10:08:51 bauzas let's not rathole on it, the answer is as of now "NOT SUPPORTED"
10:09:23 gibi as legit as requesting a brain transpart. legit but pointless if the tech is not there
10:10:18 bauzas the tech already allows us teleportation :)
10:10:41 bauzas but I hear ya
10:10:59 bauzas that would be an horrible spec to write and a terrible spec to review
10:11:28 gibi if teleportation you mean live-migration then yes libvirt has a bunch of tech implemented to support that, I'm not sure they have the tech to support brain transplant yet.
10:14:04 gibi btw that points to a direction actually. instead of shelving with a memory snapshot, do memory snapshot on the current hypervisor. The resume is supported there on the same hypevisor. I think the requesting people do not need the move aspect of shelve, they need the resumability only. So give them way to resume on same hypevisor
10:15:44 gibi wait we have that, they just get billed as they reseve the space to be able to resume
10:16:10 gibi so they don't want to get billed, but still want to make sure they can resume in place, that is contradicting
10:16:39 gibi or at least we are moving to interrutible instances territory to make space for resume
10:17:11 gibi (or what was the name of that feature that allows killing certian type of instances to make space for reservations)
10:18:43 gibi I guess I stop braindumping here as it is not exciting :)
11:06:56 sean-k-mooney[m] the reason shelve is more ligit then snapshot is it removes the snapshot once and create many copies uescase adn it also removes restore via rebuild
11:08:02 sean-k-mooney[m] so shelve/unshelve is much smaller in scope and has less sharp edges as a result
11:10:35 sean-k-mooney[m] gibi the reason sususped (which calls managed save) works today is we still have the domain so we can still restore it without worriing about the xml changing, managed save also does not allow pci passthough devices to be attached to the domain
11:12:11 sean-k-mooney[m] if i was to do shelve with memory my instict would say, save the xml and the memory as addtional images and reuse some of the live migraton logic to update the host side for it xml without modifying the guest visible side
11:12:51 sean-k-mooney[m] the same host does not really matter as long as the guest cant tell it moved
11:32:35 gibi sean-k-mooney[m]: I agree, move does not matter to the user if the instance works. I just pointing out that they also never requested the move, they only requests having a place to resume to but not getting billed for that place while suspended.
11:33:42 gibi btw having a vtpm live migration indeed seems even more important to get
11:35:06 sean-k-mooney[m] i mainly mentioned vtpm as another example of needing to store addtinoal data alongside the disk when shelving which we dont support today
11:35:44 sean-k-mooney[m] but also it a higher priority in my book but both are parralel efforts
11:37:14 parasitid hi gibi: i think i get you're point but there are still lots very obscure stuff to me because i'm definately not a specialist of this topic. When you say: "so they don't want to get billed, but still want to make sure they can resume in place, that is contradicting" why wouldn't it be possible to be resumed on a host supporting the same "flavor" ? why does it work in case of live migration and not unshelving ?. And yes i wouldn't
11:38:05 parasitid gibi: i just want to maximize the fact of being "resumable" but lowering the No Valid Host found error
11:40:03 parasitid btw, i didn't want to hijack your backlog by introducing this topic, i only wanted to know if there was a hidden feature/tips to achieve it. as it seems that its not currently supported im fine with it. don't worry.
11:41:34 gibi parasitid: no worries. I'm happy to discuss incoming request. I'm especially happy that it wasn't just a request but you are open to discuss it a bit deeper.
11:44:37 gibi parasitid: the devil is in the details of host supporting the same flavor. For nova supporting a flavor to boot a new VM on a host is differnt from supporting host as target for a live migration. And I assume it will be also different for supporting a host as a target for unshelve with memory.
11:45:08 parasitid gibi: yes. the starting point of my day was a test where i created and instance, open a vim in a tmux session, then suspended it, shelved it... Up to that point, as nova didn't complained about shelving a suspended instance, i secretly hoped that the resume would work :)
11:45:38 parasitid as i didn't find anything related to this in the docs, i jumped here to ask questions
11:46:06 gibi parasitid: what, nova allowed to shelve a suspended VM? That feels like an API validation bug :) (and also a way to raise false hope)
11:46:44 gibi parasitid: totally valid to jump and ask question. :)
11:47:59 gibi I think I'm debating mostly with bauzas about how acceptable this use case as is into our scope.
11:49:43 gibi and pointing out that even if we accept it there might me dependencies on libvirt / qemu we don't have right now to actually support it
11:50:56 gibi (and I think bauzas has a point about scope, the question boils down to how much we want to support enterprise virt vs. cloud)
11:52:17 parasitid by cloud you mean cloud native workloads ?
11:53:20 parasitid coz opening a vim in a tmux is not a cloud native workload :)
11:54:03 parasitid moreover.... i'm in the emacs team
12:01:40 gibi by cloud I mean VMs considered as cattle instead of pets
12:01:51 gibi you loose one, you create a new
12:01:57 gibi no feelings attached
12:06:01 bauzas sometimes this is a bit harder than that, like if you have some database service using memory :è)
12:07:51 gibi we have cluster aware DBs like galera. I think galera Active/Active/Active is possible. I assume that survives killing a VM
12:08:36 gibi if you only store your important data in memory then loosing that is not on nova
12:35:21 bauzas gibi: (sorry, was upgrading to F40), yeah I don't disagree with your point, I'm just saying that some cases are related to some memory usage
12:35:38 bauzas and just saying 'sorry, but cattle' doesn't help them
12:37:21 gibi I hope that it is OK to send the message that please also try to change the workload to be more cloudy. I hope this help them in the long run changing those workloads and enjoying the benefits.
12:38:07 gibi I do belive saying no sometimes actually helps :)
12:44:53 opendevreview Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590
12:44:54 opendevreview Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584
12:44:54 opendevreview Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456
12:44:55 opendevreview Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
12:55:58 gibi bauzas: can I drop the multipath_id and the novnc subpath topics from the nova meeting agenda? Or do we want to revisit them this week? I'm asking as I'm going to add https://blueprints.launchpad.net/nova/+spec/igb-vif-model to the agenda I noticed that those items might be stale
12:56:35 bauzas gibi: we discussed the multipath_id one
12:56:48 bauzas for the subpath, I think we also agreed the specless bp
12:56:51 bauzas so yeah
12:57:09 gibi OK, dropping them
12:57:26 gibi done
12:58:48 bauzas coo
12:58:51 bauzas cool even
13:05:52 opendevreview Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
13:12:20 opendevreview Brian Haley proposed openstack/nova stable/2023.2: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/916089
13:52:50 opendevreview Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
16:15:23 opendevreview Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122
#openstack-nova - 2024-09-24
08:32:05 opendevreview ribaudr proposed openstack/nova master: Amend DB model add a unique constraint. https://review.opendev.org/c/openstack/nova/+/912518
08:32:05 opendevreview ribaudr proposed openstack/nova master: Amend ShareMappingStatus due to asynchronous call https://review.opendev.org/c/openstack/nova/+/908864
08:32:06 opendevreview ribaudr proposed openstack/nova master: Use client token when talking to manila https://review.opendev.org/c/openstack/nova/+/925277
08:32:06 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194
08:32:07 opendevreview ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075
08:32:07 opendevreview ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090

Earlier   Later