With tags we can boot instances to a specified host aggregate. But in case when we need boot instances to a specified host, available zone is a good approach. Otherwise, we need to provide tagged flavors for each host. In real use I think it's quite impossible.
Best regards, Leehom Li From: Fawaz Mohammed <fawaz.moh.ibrah...@gmail.com<mailto:fawaz.moh.ibrah...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, August 22, 2016 at 4:43 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [NOVA] How boot an instance on specific compute with provider-network: physnet1 Cloud admin can add the necessary tags in the tenant flavors. On Aug 22, 2016 12:00 AM, "Jay Pipes" <jaypi...@gmail.com<mailto:jaypi...@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)" <fe...@cisco.com<mailto:fe...@cisco.com> <mailto:fe...@cisco.com<mailto:fe...@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.ge...@ericsson.com<mailto:geza.ge...@ericsson.com> <mailto:geza.ge...@ericsson.com<mailto:geza.ge...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev