[openstack-dev] [NOVA] How boot an instance on specific compute with provider-network: physnet1

Fawaz Mohammed fawaz.moh.ibraheem at gmail.com
Mon Aug 22 08:43:54 UTC 2016


Cloud admin can add the necessary tags in the tenant flavors.

On Aug 22, 2016 12:00 AM, "Jay Pipes" <jaypipes at gmail.com> wrote:

> On 08/21/2016 03:24 PM, Fawaz Mohammed wrote:
>
>> I belive utilizing host aggregate is better than availability zone in
>> this case.
>>
>
> Users don't know anything about host aggregates. They are a
> cloud-admin-only way of grouping like compute resources together and the
> end user doesn't have any way of specifying a particular host aggregate
> when launching an instance.
>
> Best,
> -jay
>
> On Aug 19, 2016 8:33 PM, "Leehom Li (feli5)" <feli5 at cisco.com
>> <mailto:feli5 at cisco.com>> wrote:
>>
>>     Hi, All
>>
>>     I used to use below command to boot an instance with a specified IP
>>     address to a
>>     Specified compute node.
>>
>>     nova boot
>>     --image <image-id> \
>>     --flavor <flavor-id> \
>>     --nic net-id=<network-id>,v4-fixed-ip=<ip addr> \
>>     --availability-zone <AZ>:<host>
>>     <Name>
>>
>>
>>
>>     May it helps.
>>
>>     leehom
>>
>>     On 8/17/16, 11:53 PM, "Géza Gémes" <geza.gemes at ericsson.com
>>     <mailto:geza.gemes at ericsson.com>> wrote:
>>
>>     >On 08/17/2016 05:38 PM, Rick Jones wrote:
>>     >> On 08/17/2016 08:25 AM, Kelam, Koteswara Rao wrote:
>>     >>> Hi All,
>>     >>>
>>     >>> I have two computes
>>     >>>
>>     >>> Compute node 1:
>>     >>> 1. physnet3:br-eth0
>>     >>>
>>     >>> 2. physnet2: br-eth2
>>     >>>
>>     >>> Compute node 2:
>>     >>> 1. physnet3:br-eth0
>>     >>> 2. physnet1:br-eth1
>>     >>> 3. physnet2:br-eth2
>>     >>>
>>     >>> When I boot an instance with a network of provider-network
>> physnet1,
>>     >>> nova is scheduling it on compute1 but there is no physnet1 on
>>     compute1
>>     >>> and it fails.
>>     >>>
>>     >>> Is there any mechanism/way to choose correct compute with correct
>>     >>> provider-network?
>>     >>
>>     >> Well, the --availability-zone option can be given a host name
>>     >> separated from an optional actual availability zone identifier by a
>>     >> colon:
>>     >>
>>     >> nova boot .. --availability-zone :hostname ...
>>     >>
>>     >> But specifying a specific host rather than just an availability
>> zone
>>     >> requires the project to have forced_host (or is it force_host?)
>>     >> capabilities.  You could, perhaps, define the two computes to be
>>     >> separate availability zones to work around that.
>>     >>
>>     >> rick jones
>>     >>
>>     >>
>>     >>
>>     >>__________________________________________________________
>> _______________
>>     >>_
>>     >>
>>     >> OpenStack Development Mailing List (not for usage questions)
>>     >> Unsubscribe:
>>     >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>     >
>>     >Hi,
>>     >
>>     >Does it help if you boot your VMs, with pre-created neutron ports,
>>     >rather than a neutron network? I think nova is supposed to bind
>>     then and
>>     >failing that it shall rescedule the VM (up to the configured
>>     re-schedule
>>     >attempts (3 by default)). I think this is an area, where e.g. one
>>     of the
>>     >physnet would relate to an SRIOV PF the PciDeviceFilter would be
>>     able to
>>     >select the right host from beginning.
>>     >
>>     >Cheers,
>>     >
>>     >Geza
>>     >
>>     >
>>     >___________________________________________________________
>> _______________
>>     >OpenStack Development Mailing List (not for usage questions)
>>     >Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>     ____________________________________________________________
>> ______________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>> >
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160822/a77dd048/attachment.html>


More information about the OpenStack-dev mailing list