Somesh, it just happened again: mysql> select * from nic_secondary_ips where ip4_address = '37.72.162.58'; +----+--------------------------------------+------+-------+--------------+-------------+------------+---------------------+------------+-----------+ | id | uuid | vmId | nicId | ip4_address | ip6_address | network_id | created | account_id | domain_id | +----+--------------------------------------+------+-------+--------------+-------------+------------+---------------------+------------+-----------+ | 14 | becda4a0-b912-4015-b69f-c9b889f74762 | 55 | 69 | 37.72.162.58 | NULL | 204 | 2015-03-19 20:35:09 | 14 | 2 | | 22 | b4b30ca2-f06c-4c1c-a048-f92678611eb2 | 5014 | 19177 | 37.72.162.58 | NULL | 204 | 2015-08-24 09:03:45 | 2 | 1 | +----+--------------------------------------+------+-------+--------------+-------------+------------+---------------------+------------+-----------+
mysql> select * from nics where id = 69\G *************************** 1. row *************************** id: 69 uuid: 23670e25-377a-40d1-ad29-0517127709b5 instance_id: 55 mac_address: 06:ba:92:00:00:46 ip4_address: 37.72.162.105 netmask: 255.255.254.0 gateway: 37.72.162.1 ip_type: Ip4 broadcast_uri: vlan://untagged network_id: 204 mode: Dhcp state: Reserved strategy: Start reserver_name: DirectPodBasedNetworkGuru reservation_id: e9f76078-6d8f-4e46-bf4c-35e2814bb8e1 device_id: 0 update_time: 2015-04-01 13:02:35 isolation_uri: NULL ip6_address: NULL default_nic: 1 vm_type: User created: 2015-03-18 14:09:53 removed: NULL ip6_gateway: NULL ip6_cidr: NULL secondary_ip: 1 display_nic: 1 There is only one entry in user_ip_address, the entry for the “new” instance, but I am sure there was an entry for the “old” instances that got overriden. -- Frank Louwers Openminds bvba T: 09/225 82 91 www.openminds.be On 21 Aug 2015 at 19:08:59, Somesh Naidu (somesh.na...@citrix.com) wrote: Frank, > That’s not really true: This is from the “nics” table in the Database: What about the removed column? Also, did you check the table user_ip_address table for the IPs? Are there multiple entries for those? If not then it should not be possible for mgmt server to assign one IP to two VMs at the same time unless the record is incorrectly not being marked as "Allocated" while assignment. Regards, Somesh -----Original Message----- From: Frank Louwers [mailto:fr...@openminds.be] Sent: Friday, August 21, 2015 3:30 AM To: users@cloudstack.apache.org Subject: Re: duplicate use of tips? On 21 Aug 2015 at 04:44:13, Abhinandan Prateek (abhinandan.prat...@shapeblue.com) wrote: If you are manually assigning the ips better use the ips that are outside the cidr that cloudstack manages. The ips assigned by cloudstack dhcp are as per cloudstack assignments anything that happen outside VR’s dhcp is unknown to cloudstack. That’s not really true: This is from the “nics” table in the Database: +-------+-------------+----------+--------------+------------+--------------+ | id | instance_id | state | ip4_address | network_id | secondary_ip | +-------+-------------+----------+--------------+------------+--------------+ | 72 | 58 | Reserved | x.y.x.92 | 204 | 1 | | 19092 | 4929 | Reserved | x.y.z.92 | 204 | 0 | +-------+-------------+----------+--------------+------------+———————+ > On 20-Aug-2015, at 11:29 pm, Frank Louwers <fr...@openminds.be> wrote: > > Hi, > > In a zone with Basic Networking, I’ve assigned a certain netblock x.y.z.0/24 > to the Guest network in CloudStack. > > I have a VM-A that has primary ip address x.y.z.92 and secondary address on > the same nic x.y.z.52. > > For various reasons, *both* ips were configured manually, so not using the > VR’s dhcp. > > A while back, the x.y.z.92 was (manually) deconfigured on VM-A (so VM-A only > used x.y.x.52, but both ips are still configured to belong to VM-A in > Cloudstack). > > A few days ago, a new instance (VM-B) was spun up, and CS assigned ip > x.y.z.92 to that VM. Why would it do that? > Today, a new instance was spun up (VM-C), but CS assigned x.y.z.52 to VM-C… > > How and why does this happen?! Is this because VM-A does not use dhcp? That > might explain the .92 re-assignement, but certainly not the .52 reassignment, > as secondary ips don’t use dhcp anyhow… > > Can anyone tell me what’s going on, and what can be done to prevent his? > Running CS 4.4.2 at the moment, considering upgrading to 4.5.1 (or 4.5.2) > > Regards, > Frank > Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
