[openstack-dev] [Heat] How about managing heat template like flavors in nova?
Hi, all When creating heat stacks, we need to specify the template path or URL, that's always inconvenient. I suggest that the heat templates should be managed in the background, just like the flavors in nova. We can supply APIs for getting, putting, adding and deleting current templates in the system, then when creating heat stacks, we just need to specify the name of the template. What's your opinion? Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SR-IOV and IOMMU check
Hi, Yang, Yi y Agree with you, IOMMU and SR-IOV need to be checked beforehand. I think it should be checked before booting a instance with the pci flavor, that means when the flavor contains some normal pci cards or SR-IOV cards. Just like when you find there are pci_requests in the instance system_metadata. The details are out of my current knows. Hope can help you. From: Yang, Yi Y [mailto:yi.y.y...@intel.com] Sent: Wednesday, March 26, 2014 10:51 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] SR-IOV and IOMMU check Hi, all Currently openstack can support SR-IOV device pass-through (at least there are some patches for this), but the prerequisite to this is both IOMMU and SR-IOV must be enabled correctly, it seems there is not a robust way to check this in openstack, I have implemented a way to do this and hope it can be committed into upstream, this can help find the issue beforehand, instead of letting kvm report the issue no IOMMU found until the VM is started. I didn't find an appropriate place to put into this, do you think this is necessary? Where can it be put into? Welcome your advice and thank you in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][PCI] problem about PCI SRIOV
Hi,
I have a problem when reading the wiki below, which is based on the latest
SRIOV design.
https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support#API_interface
My problem is about the PCI SRIOV with tagged flavor part.
In pci_information = { { 'device_id': 8086, 'vendor_id': 000[1-2] }, {
'e.physical_network': 'X' } } , I'm confused what is the e.physical_network,
if it means a network resource, why we need to filter the assignable nics by a
network resource?
Can you please tell me more about the physical_network here, thanks a lot.
In {'e.physical_netowrk':'X', 'count': 1 }, I think the count means the
count of virtual nics a SRIOV nic can support, is that right?
In the last step while booting a vm with a virtual nic, the command is nova
boot mytest --flavor m1.tiny --image=cirros-0.3.1-x86_64-uec --nic
net-id=network_X pci_flavor= '1:phyX_NIC;'.
I noticed that, pci_flavor is prompted while there already has the m1.tiny
flavor, will the pci_flavor be separated from the normal flavor in the next
step?
Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] pci device hotplug
Hello, In current PCI passthrough implementation, a pci device is only allowed to be assigned to a instance while the instance is being created, it is not allowed to be assigned or removed from the instance while the instance is running or stop. Besides, I noticed that the basic ability--remove a pci device from the instance(not by delete the flavor) has never been implemented or prompted by anyone. The current implementation: https://wiki.openstack.org/wiki/Pci_passthrough I have tested the nic hotplug on my experimental environment, it's supported by the latest libvirt and qemu. My problem is, why the pci device hotplug is not proposed in openstack until now, and is there anyone planning to do the pci device hotplug? Thanks, gouzongmei ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
