On 18 April 2016 at 04:33, Ihar Hrachyshka wrote:
> Akihiro Motoki wrote:
>
> 2016-04-18 15:58 GMT+09:00 Ihar Hrachyshka :
>>
>>> Sławek Kapłoński wrote:
>>>
>>> Hello,
What MTU have You got configured on VMs? I had issue with performance on
vxlan network with standard MTU (1500)
On 4 July 2013 23:42, Robert Collins wrote:
> Seems like a tweak would be to identify virtual IPs as separate to the
> primary IP on a port:
> you don't need to permit spoofing of the actual host IP for each host in
> the HA cluster; you just need to permit spoofing of the virtual IP. This
> woul
On 10 July 2013 21:14, Vishvananda Ishaya wrote:
>> It used to be essential back when we had nova-network and all tenants
>> ended up on one network. It became less useful when tenants could
>> create their own networks and could use them as they saw fit.
>>
>> It's still got its uses - for insta
On 17 July 2013 00:11, Jay Pipes wrote:
> Absolutely, that is what our tools team is now having to do. All I'm saying
> is that this wasn't necessary in Folsom and wouldn't be necessary if the API
> didn't force networks to be created with a tenant ID.
What's wrong with a shared network? It's be
It's already possible to port-create with an IP address-and-subnet
specified, which seems like an effective way of allocating an address
and setting it aside for later. Doesn't this satisfy your needs?
--
Ian.
On 16 July 2013 19:42, Mark McClain wrote:
> Have you considered altering the alloca
> I'd still like the simpler and more general purpose 'disable spoofing'
> option as well. That doesn't allow MAC spoofing and it doesn't work
> for what I'm up to.
Read the document properly, Ian. I take back the MAC spoofing
comment, but it still won't work for what I'm up to ;)
_
On 18 July 2013 00:45, Aaron Rosen wrote:
> Hi Ian,
>
> For shared networks if the network is set to port_security_enabled=True then
> the tenant will not be able to remove port_security_enabled from their port
> if they are not the owner of the network. I believe this is the correct
> behavior we
On 18 July 2013 19:48, Aaron Rosen wrote:
> Is there something this is missing that could be added to cover your use
> case? I'd be curious to hear where this doesn't work for your case. One
> would need to implement the port_security extension if they want to
> completely allow all ips/macs to p
> I wanted to raise another design failure of why creating the port on
> nova-compute is bad. Previously, we have encountered this bug
> (https://bugs.launchpad.net/neutron/+bug/1160442). What was causing the
> issue was that when nova-compute calls into quantum to create the port;
> quantum create
> [arosen] - sure, in this case though then we'll have to add even more
> queries between nova-compute and quantum as nova-compute will need to query
> quantum for ports matching the device_id to see if the port was already
> created and if not try to create them.
The cleanup job doesn't look like
Per the last summit, there are many interested parties waiting on PCI
support. Boris (who unfortunately waasn't there) jumped in with an
implementation before the rest of us could get a blueprint up, but I
suspect he's been stretched rather thinly and progress has been much
slower than I was hopin
A while back (just before the summit, as I recall), there was a patch
submitted to remove the constraints on being able to connect multiple
interfaces of the same VM to the same Neutron network. [1]
It was unclear at the time whether this is a bug being fixed or a
feature being added, which rather
On 22 July 2013 21:08, Boris Pavlovic wrote:
> Ian,
>
> I don't like to write anything personally.
> But I have to write some facts:
>
> 1) I see tons of hands and only 2 solutions my and one more that is based on
> code.
> 2) My code was published before session (18. Apr 2013)
> 3) Blueprints fro
> * periodic updates can overwhelm things. Solution: remove unneeded updates,
> most scheduling data only changes when an instance does some state change.
It's not clear that periodic updates do overwhelm things, though.
Boris ran the tests. Apparently 10k nodes updating once a minute
extend the
On 25 August 2014 10:34, Aryeh Friedman wrote:
> Do you call Martin Meckos having no clue... he is the one that leveled the
> second worse criticism after mine... or is Euclapytus not one the founding
> members of OpenStack (after all many of the glance commands still use it's
> name)
>
You appe
The problem here is that you've removed the vif_driver option and now
you're preventing the inclusion of named VIF types into the generic driver,
which means that rather than adding a package to an installation to add
support for a VIF driver it's now necessary to change the Nova code (and
repackag
Aaron: untrue. It does, but OVS doesn't, and so networks implemented with
the OVS driver will drop packets. Use Linuxbridge instead.
--
Ian.
On 19 September 2014 22:27, Aaron Rosen wrote:
> Neutron doesn't allow you to send tagged traffic from the guest today
> https://github.com/openstack/ne
On 3 April 2014 08:21, Khanh-Toan Tran wrote:
> Otherwise we cannot provide redundancy to client except using Region which
> is dedicated infrastructure and networked separated and anti-affinity
> filter which IMO is not pragmatic as it has tendency of abusive usage.
>
I'm sorry, could you explai
On 8 April 2014 10:35, Zane Bitter wrote:
> To attach a port to a network and give it an IP from a specific subnet
>
>> on that network, you would use the *--fixed-ip subnet_id *option.
>>
>> Otherwise, the create port request will use the first subnet it finds
>> attached to that network to allo
1. [NFV] is a tag.
2. This would appear to be a set of 'review me' mails to the mailing list,
which I believe is frowned upon.
3. garyk's stuff is only questionably [NFV], I would argue, though all
worthwhile patches. (That's a completely subjective judgement, so take it
as you will.)
Might be a b
On 7 July 2014 10:43, Andrew Mann wrote:
> What's the use case for an IPv6 endpoint? This service is just for
> instance metadata, so as long as a requirement to support IPv4 is in place,
> using solely an IPv4 endpoint avoids a number of complexities:
>
- Which one to try first?
>
http://en.wik
On 7 July 2014 11:37, Sean Dague wrote:
> > When it's on a router, it's simpler: use the nexthop, get that metadata
> > server.
>
> Right, but that assumes router control.
>
It does, but then that's the current status quo - these things go on
Neutron routers (and, by extension, are generally not
On 7 July 2014 12:29, Scott Moser wrote:
>
> > I'd honestly love to see us just deprecate the metadata server.
>
> If I had to deprecate one or the other, I'd deprecate config drive. I do
> realize that its simplicity is favorable, but not if it is insufficient.
>
The question of deprecation is
I hadn't realised until today that the BP window for new Nova specs in Juno
had closed, and I'm hoping I might get an exception for a minor, but I
think helpful, change in the way VIF plugging works.
At the moment, Neutron's plugin returns a binding_type to Nova when
plugging takes place, describi
On 10 July 2014 08:19, Czesnowicz, Przemyslaw <
przemyslaw.czesnow...@intel.com> wrote:
> Hi,
>
>
>
> Thanks for Your answers.
>
>
>
> Yep using binding:vif_details makes more sense. We would like to reuse
> VIF_TYPE_OVS and modify the nova to use the userspace vhost when ‘use_dpdk’
> flag is pre
Funnily enough, when I first reported this bug I was actually trying to run
Openstack in VMs on Openstack. This works better now (not well; just
better) in that there's L3 networking options, but the basic L2-VLAN
networking option has never worked (fascinating we can't eat our own
dogfood on this
On 14 July 2014 12:57, Collins, Sean
wrote:
> The URL structure and schema of data within may be 100% openstack invented,
> but the idea of having a link local address that takes HTTP requests and
> returns metadata was (to my knowledge) an Amazon EC2 idea from the
> beginning.
>
'link local' -
Speaking as someone who was reviewing both specs, I would personally
recommend you grant both exceptions. The code changes are very limited in
scope - particularly the Nova one - which makes the code review simple, and
they're highly unlikely to affect anyone who isn't actually using DPDK OVS
(sub
On 23 July 2014 10:52, Dan Smith wrote:
> > What is our story for people who are developing new network or
> > storage drivers for Neutron / Cinder and wish to test Nova ? Removing
> > vif_driver and volume_drivers config parameters would mean that they
> > would have to directly modify the exist
On 4 August 2014 07:03, Elena Ezhova wrote:
> Hi!
>
> I feel I need a piece of advice regarding this bug [1].
>
> The gist of the problem is that although there is an option
> network_device_mtu that can be specified in neutron.conf VMs are not
> getting that mtu on their interfaces.
>
Correct.
On 13 August 2014 06:01, Kyle Mestery wrote:
> On Wed, Aug 13, 2014 at 5:15 AM, Daniel P. Berrange
> wrote:
> > This idea of fixed slots is not really very appealing to me. It sounds
> > like we're adding a significant amount of buerocratic overhead to our
> > development process that is going t
Next time, could you perhaps do it (a) with a bit more notice and (b) at a
slightly more amenable time for us Europeans?
On 4 December 2013 15:27, Richard Woo wrote:
> Shixiong,
>
> Thank you for the updates, do you mind to share the slide to the openstack
> mailing list?
>
> Richard
>
>
> On T
How frequent do you imagine these notifications being? There's a wide
variation here between the 'blue moon' case where disk space is low and
frequent notifications of things like OS performance, which you might want
to display in Horizon or another monitoring tool on an every-few-seconds
basis, o
We seem to have bound our config drive file formats to those used by the
operating system we're running, which doesn't seem like the right approach
to take.
Firstly, the above format doesn't actually work even for Debian-based
systems - if you have a network without ipv6, ipv6 ND will be enabled o
On 20 November 2013 00:22, Robert Collins wrote:
> On 20 November 2013 13:00, Sean Dague wrote:
> > So we recently moved devstack gate to do con fig drive instead of
> metadata
> > service, and life was good (no one really noticed). In what ways is
> > configdrive insufficient compared to metada
I would imagine that, from the Neutron perspective, you get a single router
whether or not it's distributed. I think that if a router is distributed -
regardless of whether it's tenant-tenant or tenant-outside - it certainly
*could* have some sort of SLA flag, but I don't think a simple
'distribut
On 10 December 2013 20:55, Clint Byrum wrote:
> If it is just a network API, it works the same for everybody. This
> makes it simpler, and thus easier to scale out independently of compute
> hosts. It is also something we already support and can very easily expand
> by just adding a tiny bit of f
Are these NSX routers *functionally* different?
What we're talking about here is a router which, whether it's distributed
or not, behaves *exactly the same*. So as I say, maybe it's an SLA thing,
but 'distributed' isn't really user meaningful if the user can't actually
prove he's received a distr
the Havana summit, but no one ever
> made any progress. There was some debate about whether there was an
> existing xml format and someone was going to investigate. Since this has
> not happened, I propose we scrap that idea and just produce the network
> info in json.
>
> Nova should b
On 12 December 2013 19:48, Clint Byrum wrote:
> Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800:
> > On 12/10/2013 03:49 PM, Ian Wells wrote:
> > > On 10 December 2013 20:55, Clint Byrum > > <mailto:cl...@fewbar.com>> wrote:
> > I&#x
Can we go over the use cases for the multiple different address allocation
techniques, per my comment on the blueprint that suggests we expose
different dnsmasq modes?
And perhaps also what we're going to do with routers in terms of equivalent
behaviour for the current floating-ip versus no-floati
On 13 December 2013 16:13, Alessandro Pilotti <
apilo...@cloudbasesolutions.com> wrote:
> 2) The HTTP metadata service accessible from the guest with its magic
> number is IMO quite far from an optimal solution. Since every hypervisor
> commonly
> used in OpenStack (e.g. KVM, XenServer, Hyper-V, E
rings
benefits but we can do without.
--
Ian.
On 17 December 2013 21:41, Collins, Sean wrote:
> On Tue, Dec 17, 2013 at 07:39:14PM +0100, Ian Wells wrote:
> > 1. The patch ties Neutron's parameters specifically to dnsmasq. It would
> > be, I think, impossible to reimplement
On 17 December 2013 18:57, Shixiong Shang wrote:
> Yes, the man page is a little bit confusing. The “slaac” mode requires
> “—enable-ra” since it needs to manipulate MOAL bits in the RA. As matter of
> fact, all of the modes available for IPv6 rely on “—enable-ra”.
>
> My understanding is, the ra-
Hey Shixiong,
This is intended as a replacement for [1], correct? Do you have code for
this already, or should we work with Sean's patch?
There's a discussion document at [2], which is intended to be more specific
behind the reasoning for the choices we make, and the interface offered to
the use
I think we're all happy that if a project *does* have a broad support base
we're good; this is only the case for projects in one of two situations:
- support is spread so thinly that each company involved in the area has
elected to support a different solution
- the project is just not that interes
A Neutron network is analagous to a wire between ports. We can do almost
everything with this wire - we can pass both IP and non-IP traffic, I can
even pass MPLS traffic over it (yes, I tried). For no rational reason, at
least if you live north of the API, I sometimes can't pass VLAN traffic
ove
On 18 December 2013 14:10, Shixiong Shang wrote:
> Hi, Ian:
>
> I won’t say the intent here is to replace dnsmasq-mode-keyword BP.
> Instead, I was trying to leverage and enhance those definitions so when
> dnsmasq is launched, it knows which mode it should run in.
>
> That being said, I see the v
John:
> At a high level:
>
> Neutron:
> * user wants to connect to a particular neutron network
> * user wants a super-fast SRIOV connection
Administration:
> * needs to map PCI device to what neutron network the connect to
>
The big question is:
> * is this a specific SRIOV only (provider) netwo
On 19 December 2013 06:35, Isaku Yamahata wrote:
>
> Hi Ian.
>
> I can't see your proposal. Can you please make it public viewable?
>
Crap, sorry - fixed.
> > Even before I read the document I could list three use cases. Eric's
> > covered some of them himself.
>
> I'm not against trunking.
>
I'm easy.
On 20 December 2013 00:47, Randy Tuttle wrote:
> Any of those times suit me.
>
> Sent from my iPhone
>
> On Dec 19, 2013, at 5:12 PM, "Collins, Sean" <
> sean_colli...@cable.comcast.com> wrote:
>
> > Thoughts? I know we have people who are not able to attend at our
> > current time.
>
ll share with the team tomorrow.
>>
>> That being said, what concerned me the most at this moment is, we are not
>> on the same page. I hope tomorrow during sub-team meeting, we can reach
>> consensus. If you can not make it, then please set up a separate meeting to
>&
Per the discussions this evening, we did identify a reason why you might
need a dhcp namespace for v6 - because networks don't actually have to have
routers. It's clear you need an agent in the router namespace for RAs and
another one in the DHCP namespace for when the network's not connected to a
On 19 December 2013 15:15, John Garbutt wrote:
> > Note, I don't see the person who boots the server ever seeing the
> pci-flavor, only understanding the server flavor.
> > [IrenaB] I am not sure that elaborating PCI device request into server
> flavor is the right approach for the PCI pass-thro
pace?
>
> It is because we intentionally separate the service, now the system become
> clumsy and less efficient. As you can see in IPv6 cases, we are forced to
> deal with two namespaces now. It just doesn’t make any sense.
>
> Shixiong
>
>
>
>
>
>
> On Dec 19,
Randy has it spot on. The antispoofing rules prevent you from doing this
in Neutron. Clearly a router transmits traffic that isn't from it, and
receives traffic that isn't addressed to it - and the port filtering
discards them.
You can disable them for the entire cloud by judiciously tweaking th
ng a L2-gateway directly to the
> Neutron 'vNic' port, or some other solution. IMHO it would be good to map
> VLAN to Neutron network as soon as possible.
>
> Thanks,
> Erik
>
>
>
> On Thu, Dec 19, 2013 at 2:15 PM, Ian Wells wrote:
>
>> On 19 Decem
On autodiscovery and configuration, we agree that each compute node finds
out what it has based on some sort of list of match expressions; we just
disagree on where they should live.
I know we've talked APIs for setting that matching expression, but I would
prefer that compute nodes are responsibl
See Sean Collins' review https://review.openstack.org/#/c/56381 which
disables hairpinning when Neutron is in use. tl;dr - please upvote the
review. Long form reasoning follows...
There's a solid logical reason for enabling hairpinning, but it only
applies to nova-network. Hairpinning is used i
I think I'm in agreement with all of this. Nice summary, Robert.
It may not be where the work ends, but if we could get this done the rest
is just refinement.
On 9 January 2014 17:49, Robert Li (baoli) wrote:
>Hi Folks,
>
> With John joining the IRC, so far, we had a couple of produc
On 9 January 2014 20:19, Brian Schott wrote:
> Ian,
>
> The idea of pci flavors is a great and using vendor_id and product_id make
> sense, but I could see a case for adding the class name such as 'VGA
> compatible controller'. Otherwise, slightly different generations of
> hardware will mean cust
On 9 January 2014 22:50, Ian Wells wrote:
> On 9 January 2014 20:19, Brian Schott wrote:
> On the flip side, vendor_id and product_id might not be sufficient.
> Suppose I have two identical NICs, one for nova internal use and the
> second for guest tenants? So, bus numbering may
On 10 January 2014 07:40, Jiang, Yunhong wrote:
> Robert, sorry that I’m not fan of * your group * term. To me, *your
> group” mixed two thing. It’s an extra property provided by configuration,
> and also it’s a very-not-flexible mechanism to select devices (you can only
> select devices based o
in
short order.
--
Ian.
On 10 January 2014 13:08, Ian Wells wrote:
> On 10 January 2014 07:40, Jiang, Yunhong wrote:
>
>> Robert, sorry that I’m not fan of * your group * term. To me, *your
>> group” mixed two thing. It’s an extra property provided by configuration,
>
On 10 January 2014 15:30, John Garbutt wrote:
> We seemed happy with the current system (roughly) around GPU passthrough:
> nova flavor-key set
> "pci_passthrough:alias"=" large_GPU:1,small_GPU:2"
> nova boot --image some_image --flavor
>
Actually, I think we pretty solidly disagree on this p
Hey Yunhong,
The thing about 'group' and 'flavor' and 'whitelist' is that they once
meant distinct things (and I think we've been trying to reduce them back
from three things to two or one):
- group: equivalent devices at a host level - use any one, no-one will
care, because they're either identi
On 11 January 2014 00:04, Jiang, Yunhong wrote:
> [yjiang5] Really thanks for the summary and it is quite clear. So what’s
> the object of “equivalent devices at host level”? Because ‘equivalent
> device * to an end user *” is flavor, so is it ‘equivalent to **scheduler**”
> or ‘equivalent to **
Hey Luke,
If you look at the passthrough proposals, the overview is that part of the
passthrough work is to ensure there's an PCI function available to allocate
to the VM, and part is to pass that function on to the Neutron plugin via
conventional means. There's nothing that actually mandates tha
>
> OK - so if this is good then I think the question is how we could change
the 'pci_whitelist' parameter we have - which, as you say, should either
*only* do whitelisting or be renamed - to allow us to add information.
Yongli has something along those lines but it's not flexible and it
distingui
ot;network_ids": ["*"] # this means could attach to any network } }
>
> The idea being the VIF driver gets passed this info, when network_info
> includes a nic that matches.
> Any other details, like VLAN id, would come from neutron, and passed to
> the VIF driver as normal.
for your earlier help with
> working this out :)). The idea is to put the SR-IOV hardware to work
> behind-the-scenes of a normal software switch.
>
> We will definitely check out the Passthrough when it's ready and see
> if we should also support that somehow.
>
>
> O
I would say that since v4 dhcp_mode is core, the DHCPv6/RA setting should
similarly be core.
To fill others in, we've had discussions on the rest of the patch and
Shixiong is working on it now, the current plan is:
New subnet attribute ipv6_address_auto_config (not catchy, but because of
the way
But regardless, it introduces tremendous overhead in
> terms of system processing and administrative costs.
>
>
>
> What are the use cases for that? How practical are those use cases?
>
>
>
> thanks,
>
> Robert
>
>
>
> On 1/10/14 9:34 PM, "Ian Wells&qu
;
>
>
> Thanks
>
> --jyh
>
>
>
> *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk]
> *Sent:* Monday, January 13, 2014 10:57 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova] [neutron] PCI pass-through
Logically, the port is really an alias for the external port of the router,
rather than being just detached. I'm not sure this adds much to the
discussion, but clearly that's where its traffic goes and is terminated.
>From past experience (don't ask) weird things happen if you start creating
your
To clarify a couple of Robert's points, since we had a conversation earlier:
On 15 January 2014 23:47, Robert Li (baoli) wrote:
> --- do we agree that BDF address (or device id, whatever you call it),
> and node id shouldn't be used as attributes in defining a PCI flavor?
>
Note that the curr
On 16 January 2014 10:51, Robert Collins wrote:
> > 1. assigned to the interface attached to default gateway
>
Which you may not have, or may be on the wrong interface (if I'm setting up
a control node I usually have the default gateway on the interface with the
API endpoints, which I emphatical
On 16 January 2014 09:07, yongli he wrote:
> On 2014年01月16日 08:28, Ian Wells wrote:
>
> This is based on Robert's current code for macvtap based live migration.
> The issue is that if you wish to migrate a VM and it's tied to a physical
> interface, you can't gu
On 17 January 2014 01:16, Chris Friesen wrote:
> On 01/16/2014 05:12 PM, CARVER, PAUL wrote:
>
> Jumping back to an earlier part of the discussion, it occurs to me
>> that this has broader implications. There's some discussion going on
>> under the heading of Neutron with regard to PCI passthrou
On 17 January 2014 09:12, Robert Collins wrote:
> > The physical function is the one with the "real" PCI config space, so as
> > long as the host controls it then there should be minimal risk from the
> > guests since they have limited access via the virtual
> functions--typically
> > mostly just
On 20 January 2014 09:28, Irena Berezovsky wrote:
> Hi,
> Having post PCI meeting discussion with Ian based on his proposal
> https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit?pli=1#
> ,
> I am not sure that the case that quite usable for SR-IOV based networkin
On 20 January 2014 10:13, Mathieu Rohon wrote:
> With such an architecture, we wouldn't have to tell neutron about
> vif_security or vif_type when it creates a port. When Neutron get
> called with port_create, it should only return the tap created.
>
Not entirely true. Not every libvirt port is
duling for both PCI and
non-PCI cases.
--
Ian.
On 20 January 2014 13:38, Ian Wells wrote:
> On 20 January 2014 09:28, Irena Berezovsky wrote:
>
>> Hi,
>> Having post PCI meeting discussion with Ian based on his proposal
>> https://docs.google.com/document/d/1vadqmurln
Paul,
There's an extension for this that is, I think, presently only implemented
by the Nicira plugin. Look for portsecurity. Whatever they do is probably
the way you should do it too.
Cheers,
--
Ian.
On 21 January 2014 13:10, CARVER, PAUL wrote:
> Feel free to tell me this is a bad idea
Hi,
We've had a few comments about creating a new table specifically for PCI
flavors versus using the already existing host aggregates table, and John
Garbutt asked me to explain the concepts involved here to see what the body
of opinion was on the subject. My opinion, which which this account is
On 21 January 2014 21:23, Robert Collins wrote:
> In OpenStack we've got documentation[1] that advises setting a low MTU
> for tenants to workaround this issue (but the issue itself is
> unsolved) - this is a problem because PMTU is fairly important :)
> Lowering *every* tenant when one tenant so
/30 is the minimum allowable mask, not /31.
On 21 January 2014 22:04, Edgar Magana wrote:
> Wouldn't be easier just to check if:
>
> cidr is 32?
>
> I believe it is a good idea to not allow /32 network but this is just my
> opinion
>
> Edgar
>
> From: Paul Ward
> Reply-To: OpenStack List
> Da
On 22 January 2014 00:00, Robert Collins wrote:
> I think dropping frames that can't be forwarded is entirely sane - at
>
a guess it's what a physical ethernet switch would do if you try to
> send a 1600 byte frame (on a non-jumbo-frame switched network) - but
> perhaps there is an actual standar
On 22 January 2014 12:01, Robert Collins wrote:
> > Getting the MTU *right* on all hosts seems to be key to keeping your hair
> > attached to your head for a little longer. Hence the DHCP suggestion to
> set
> > it to the right value.
>
> I certainly think having the MTU set to the right value i
On 21 January 2014 22:46, Veiga, Anthony wrote:
>
>Hi, Sean and Xuhan:
>
> I totally agree. This is not the ultimate solution with the assumption
> that we had to use “enable_dhcp”.
>
> We haven’t decided the name of another parameter, however, we are open
> to any suggestions. As we mention
On 27 January 2014 15:58, Robert Li (baoli) wrote:
> Hi Folks,
>
> In today's meeting, we discussed a scheduler issue for SRIOV. The basic
> requirement is for coexistence of the following compute nodes in a cloud:
> -- SRIOV only compute nodes
>
-- non-SRIOV only compute nodes
>
Live migration for the first release is intended to be covered by macvtap,
in my mind - direct mapped devices have limited support in hypervisors
aiui. It seemed we had a working theory for that, which we test out and
see if it's going to work.
--
Ian.
On 27 January 2014 21:38, Robert Li (baoli
My proposals:
On 29 January 2014 16:43, Robert Li (baoli) wrote:
> 1. pci-flavor-attrs is configured through configuration files and will be
> available on both the controller node and the compute nodes. Can the cloud
> admin decide to add a new attribute in a running cloud? If that's
> possible
On 29 January 2014 23:50, Robert Kukura wrote:
> On 01/29/2014 05:44 PM, Robert Li (baoli) wrote:
> > Hi Bob,
> >
> > that's a good find. profileid as part of IEEE 802.1br needs to be in
> > binding:profile, and can be specified by a normal user, and later
> possibly
> > the pci_flavor. Would it
There are two categories of problems:
1. some networks don't pass VLAN tagged traffic, and it's impossible to
detect this from the API
2. it's not possible to pass traffic from multiple networks to one port on
one machine as (e.g.) VLAN tagged traffic
(1) is addressed by the VLAN trunking network
On 25 October 2014 15:36, Erik Moe wrote:
> Then I tried to just use the trunk network as a plain pipe to the
> L2-gateway and connect to normal Neutron networks. One issue is that the
> L2-gateway will bridge the networks, but the services in the network you
> bridge to is unaware of your exist
Path MTU discovery works on a path - something with an L3 router in the way
- where the outbound interface has a smaller MTU than the inbound one.
You're transmitting across an L2 network - no L3 routers present. You send
a 1500 byte packet, the network fabric (which is not L3, has no address,
and
o trunk ports or networks.
> 4. Will there be requirement to handle Nested tagged packet on
> such interfaces ?
>
For trunking ports, I don't believe anyone was considering it.
>
>
>
>
>
>
> Thanks & Regards,
>
> Keshava
>
>
>
> *From:*
sn't generally change, and I think we would
forbid changing the MTU of a network after creation. It's only an initial
configuration thing, therefore. It might involve better cloud-init support
for network configuration, something that gets discussed periodically.
--
Ian.
>
ection choked, from the bridge in compute host we can see
> the sender send packets, and the receiver can not get the packets.
> If it is the pmtud, then at the very begining, the packet can not transmit
> from the begining.
>
> At 2014-10-28 14:10:09, "Ian Wells" wrote:
&
1 - 100 of 218 matches
Mail list logo
