From cloudstack-users-return-5280-apmail-incubator-cloudstack-users-archive=incubator.apache.org@incubator.apache.org Tue Mar 19 21:36:16 2013 Return-Path: X-Original-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4CF75F85A for ; Tue, 19 Mar 2013 21:36:16 +0000 (UTC) Received: (qmail 46187 invoked by uid 500); 19 Mar 2013 21:36:15 -0000 Delivered-To: apmail-incubator-cloudstack-users-archive@incubator.apache.org Received: (qmail 46158 invoked by uid 500); 19 Mar 2013 21:36:15 -0000 Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-users@incubator.apache.org Delivered-To: mailing list cloudstack-users@incubator.apache.org Received: (qmail 46148 invoked by uid 99); 19 Mar 2013 21:36:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Mar 2013 21:36:15 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kirkkosinski@gmail.com designates 209.85.192.174 as permitted sender) Received: from [209.85.192.174] (HELO mail-pd0-f174.google.com) (209.85.192.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Mar 2013 21:36:08 +0000 Received: by mail-pd0-f174.google.com with SMTP id 10so326151pdi.5 for ; Tue, 19 Mar 2013 14:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Gs52jRXQNh+2Bsus19jU/XMu9roFIA0k6y6zYpq3HoI=; b=n81z2Ut/J4upv6gdqW0LnoqbA4O3HMlAjB9vd4gEVyKwZsw9cQOZGmJtt8v1kjFMjV OgewjJs5+NWcPrSBXS9lxNtdaV+oK+dMnmoXT2URMhhj/kuGDfKJXqmVYJsHmeAHkXXk XJ02AWAtx1TMwMw6Vza2TgwibdPoytIimM0NfIP2XNWryt15lCX/Ozccjr3KAGmsGf14 4FwJlJWQIFV1aIgSitxCcbr9/O5EklPyl2FZqSj6kMyT+USMP8nYIsA0Uh0i0V+hrfqe 8neDpCMqp0pS4PxzysAgusgHv+DpX3YQKXoyQNcYPKNUAANgInU125QV8Mx8u3wiR8yP ZliA== X-Received: by 10.66.160.225 with SMTP id xn1mr1654043pab.136.1363728947123; Tue, 19 Mar 2013 14:35:47 -0700 (PDT) Received: from [172.20.0.59] (dsl081-233-032.lax1.dsl.speakeasy.net. [64.81.233.32]) by mx.google.com with ESMTPS id ax3sm25596057pbd.42.2013.03.19.14.35.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Mar 2013 14:35:46 -0700 (PDT) Message-ID: <5148DA30.4010106@gmail.com> Date: Tue, 19 Mar 2013 14:35:44 -0700 From: Kirk Kosinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.3 MIME-Version: 1.0 To: cloudstack-users@incubator.apache.org Subject: Re: How cloudstack assign ip to link-local? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org CloudStack communicates to system VMs on KVM and XenServer indirectly; the host OS will SSH to the system VMs on behalf of CloudStack to run commands. For this scenario it is possible for system VMs to have a NIC on an unrouted network that only the hypervisor can access. This is not done on VMware since the host OS is locked down and missing many commands (e.g. no "ssh" command), so CloudStack will SSH directly to system VMs on VMware. VMware system VMs therefore have an interface on the private/management network that is accessible to CloudStack. Best regards, Kirk On 03/19/2013 07:45 AM, Wang Fei wrote: > AFAIK, Vmware does not support link-local interfaces. But in practice, in > my Vmware based zone, the SSVM and CPVM did not contain this interface. But > the VR not only created this interface. but the ip address is in the same > vlan with private ip network. and I can login to VR by ssh with the > link-local ip address. > > according the wiki item, "Link-local addresses for IPv4 are defined in the > address block 169.254.0.0/16". why the link-local address of VR was not in > this subnet? why vmware can create the link-local interface for VR but SSVM > and CPVM? > > > > ---- > best regards >