Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-12
13:09:06 sean-k-mooney right its only used to get teh mdevs
13:09:07 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3237
13:09:49 aspiers so maybe I can set an _sev_required instance variable in spawn()
13:10:26 aspiers or somewhere underneath that
13:10:26 sean-k-mooney well you could jsut pass the allcoation to _get_guest_xml
13:10:45 aspiers that's a good idea
13:10:57 aspiers I guess I only need it for constructing XML
13:11:02 aspiers so that would scope it correctly
13:11:20 aspiers hopefully efried will come online before I disappear down this rathole :)
13:12:33 sean-k-mooney its still a little messy
13:12:43 sean-k-mooney i think really we want to add the allcotion to the instance
13:13:02 sean-k-mooney that way you dont need to pass a new param all over the place
13:13:07 aspiers yeah
13:13:16 sean-k-mooney and i think more things will need the allocation in the future anyway
13:13:54 sean-k-mooney we track things like pci device allcotation in teh instance already so i think that is the best path forward.
13:14:18 aspiers sounds reasonable but I can't really comment
13:15:17 sean-k-mooney efried: when you are online any objection to adding the allocations form placmenet to the instnace object?
13:21:46 artom sean-k-mooney, sorta like network_info in info_cache?
13:22:14 sean-k-mooney not quite although kind of
13:23:11 sean-k-mooney artom: we store the list of pci devices allocated to an instance in the instance
13:23:13 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L200
13:23:33 sean-k-mooney so that we can use the same ones on reboot
13:23:58 sean-k-mooney it would be somewhat like storing the vifs in the info_cache
13:24:23 sean-k-mooney but keeping the allocation in the insantce so we dont have to look them up on swapn or reboot makes sense
13:24:59 sean-k-mooney *start or reboot
13:30:15 sean-k-mooney ...
13:30:31 sean-k-mooney i think our vgpu code is busted
13:31:21 sean-k-mooney bauzas: did you ever test stopping an instance with vgpus
13:31:29 sean-k-mooney then starting it again
13:32:48 sean-k-mooney power_on in the libvirt driver delegate to _hard_reboot which assumes the xml still exists to get the mdevs from
13:32:50 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2897-L2900
13:33:01 sean-k-mooney power_off calls destroy
13:33:33 sean-k-mooney so if you shutdown an instance with vgpus and then start it again it wont have vgpus...
13:39:19 kashyap Speaking of assigned devices, somepeople might find this tool ("mdevctl") useful: https://github.com/awilliam/mdevctl
13:39:28 kashyap More info and background about it here:
13:39:40 kashyap https://www.redhat.com/archives/libvir-list/2019-May/msg00722.html
13:39:44 kashyap ("mdevctl: A shoestring mediated device management and persistence utility")
13:40:09 kashyap It's a shell tool. So, be gentle with your eyes :D
13:40:11 sean-k-mooney ya maybe
13:41:44 sean-k-mooney they are not that hard to manage i personlaly would praobly do it with systemd rather then udev personally
13:42:24 kashyap I don't know, if the VFIO maintainer suggests that, then I'd go the route they suggest.
13:44:43 sean-k-mooney perhaps if it existited when i started managing mdev like 2 years ago maybe i think its still failly tivial to do yourself too
13:47:17 sean-k-mooney kashyap: this is the striped down lib we created for managian mdevs for smart nics last year https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/networking_vhost_vfio/mdev/mdev.py
13:47:42 kashyap sean-k-mooney: If it were "trivial", why would they write that tool?
13:47:55 sean-k-mooney it does not do persistence but at the time i also looked into doing it with systemd
13:48:34 sean-k-mooney kashyap: because they felt like it? just because its trivial to do does not mean you dont have to do it alot and still want to automate it
13:49:41 openstackgerrit Merged openstack/nova master: Make get_provider_by_name public and remove safe_connect https://review.opendev.org/664062
13:50:18 rafaelweingartne Hello guys, is there an "openstack server event list" command like that is able to list the events for deleted VMs?
13:52:04 sean-k-mooney im not sure that is what that is for
13:52:14 rafaelweingartne no?
13:52:41 sean-k-mooney i think it list the life cycle events a server has undergone
13:52:49 sean-k-mooney i dont think you can use it to wait for an event
13:53:02 rafaelweingartne It looks like it is presenting he vents I need/want such as attaching something, and or creating the vm
13:53:07 rafaelweingartne ah
13:53:11 rafaelweingartne no, I do not want to wait
13:53:29 kashyap sean-k-mooney: It's not "they felt like it"; there's a proper rationale there.
13:53:39 kashyap [quote]
13:53:40 kashyap everyone's needs on the first pass, but maybe we'll solve enough and
13:53:40 kashyap provide something and see where it goes. I doubt we'll solve
13:53:40 kashyap is largely left as an exercise for the user. This is an attempt to
13:53:40 kashyap Currently mediated device management, much like SR-IOV VF management,
13:53:41 rafaelweingartne I just want to list all events that already happened to a VM
13:53:42 kashyap provide helpers for the rest. Without further ado, I'll point to what
13:53:45 kashyap I have so far:
13:53:47 kashyap [/quote]
13:54:28 rafaelweingartne sean-k-mooney: I think your reply was not meant for me
13:54:32 rafaelweingartne sorry ;)
13:54:36 sean-k-mooney kashyap: sure but its proably not the first attempt to do that either
13:55:15 sean-k-mooney rafaelweingartne: no it was
13:55:55 sean-k-mooney i was stating that cli command is to show the list of event that server has undergon. but im currently confiming
13:56:09 rafaelweingartne ah o
13:56:10 rafaelweingartne ok
13:56:16 rafaelweingartne but that is actually what I want/need
13:56:26 rafaelweingartne to list everything that has already happened to a VM
13:56:36 rafaelweingartne the problem is that it only works for VMs that have not beeing deleted
13:56:51 rafaelweingartne or at least, I was not able to use it for deleted VMs
13:58:06 sean-k-mooney deleted or soft deleted
13:58:36 rafaelweingartne the difference is not that clear to me
13:58:42 rafaelweingartne deleted
14:01:44 sean-k-mooney this is basically showing the events form the instance action log
14:02:18 sean-k-mooney i did not think we removed that when we deleted an instace provided you have not archive teh deleted instances or purged them form the db
14:02:30 sean-k-mooney but maybe we do not allow you to retrive the info
14:03:03 rafaelweingartne that is what I thought
14:03:10 rafaelweingartne is this implemented in Nova API?
14:03:33 rafaelweingartne or is it somewhere else? where I can take a look and maybe propose a method to retrieve data for deleted VMs as well
14:04:24 sean-k-mooney i think its hitting this endpoint https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail
14:05:37 sean-k-mooney actully no that is not correct
14:06:33 sean-k-mooney its hitting the server action endpoint
14:06:35 sean-k-mooney https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail,list-actions-for-server-detail#list-actions-for-server
14:07:51 rafaelweingartne cool thanks
14:08:11 rafaelweingartne I was looking for "/servers/{server_id}/events"...
14:08:20 rafaelweingartne now I know why I did not find it
14:08:42 rafaelweingartne What does this "Action information of deleted instances can be returned for requests starting with microversion 2.21." mean?
14:08:53 rafaelweingartne Nova version?
14:09:02 rafaelweingartne Nova-compute*
14:09:35 sean-k-mooney the nova api support microversion form v2.1 on
14:09:43 sean-k-mooney but the openstack client does not use them
14:09:47 sean-k-mooney it default to 2.1
14:10:08 sean-k-mooney so if you want to get it to work you have to pass a a microverion of at lest 2.21
14:10:14 sean-k-mooney one sec

Earlier   Later