Re: Reserved Guest VM CIDR Question
Hi Saksham, Thanks, I'll give that a shot. Thank You, Logan Barfield Tranquil Hosting On Tue, Oct 7, 2014 at 1:25 AM, Saksham Srivastava saksham.srivast...@citrix.com wrote: Logan, The reason why reservation is not enabled in create stage is the case of External network devices. When using external devices like NetScaler, CloudStack will not have a 'real' cidr unless the network has been implemented. So a cidr like /24 used at time of create may turn to /20 when the network has been implemented and then it make no sense for reservation in initial stage. What I will suggest is to create a network offering with 'Persistent' as true. So your network will be implemented when you create it and VR will be up. Once the network has been implemented you can apply reservation. Thanks, Saksham -Original Message- From: Logan Barfield [mailto:lbarfi...@tqhosting.com] Sent: Tuesday, October 7, 2014 12:27 AM To: dev@cloudstack.apache.org Subject: Reserved Guest VM CIDR Question We have decided internally to set up a CIDR reservation with all new accounts to give us the ability to easily attach dedicated hosts to existing VM networks. We were thinking it would be easier to set up the reservation before deploying VMs. Setting up reservation after the fact can get complicated if a VM happens to be outside the intended reservation range. The issue we're having is that reservation is not allowed until the network is in the Implemented state (i.e. after the first VM is deployed). Why is reservation not allowed upon initial network creation? If we try to apply reservation after the first VM is online the command will fail occasionally because the first VM is deployed outside the CIDR range. Example: Guest Net: 10.1.1.0/24 Reserved CIDR: 10.1.1.0/25 - Attempt reservation before deploying a VM: Fails due to network not being Implemented - Attempt reservation after many VMs are deployed: Fails due to VMs being outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change the VM's IP - Attempt reservation after first VM is deployed: Either succeeds, or fails if the first VMs IP is outside of the reserved CIDR. How can we fix this without hacking work arounds into the deployment logic? (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that IP, if it already exists deploy it wherever.) Thank You, Logan Barfield Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Do startip and endip createNetwork parameters not work for that (when creating the network? That should carve out a subset of the network for cloudstack use and leave the rest untouched. On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com wrote: We have decided internally to set up a CIDR reservation with all new accounts to give us the ability to easily attach dedicated hosts to existing VM networks. We were thinking it would be easier to set up the reservation before deploying VMs. Setting up reservation after the fact can get complicated if a VM happens to be outside the intended reservation range. The issue we're having is that reservation is not allowed until the network is in the Implemented state (i.e. after the first VM is deployed). Why is reservation not allowed upon initial network creation? If we try to apply reservation after the first VM is online the command will fail occasionally because the first VM is deployed outside the CIDR range. Example: Guest Net: 10.1.1.0/24 Reserved CIDR: 10.1.1.0/25 - Attempt reservation before deploying a VM: Fails due to network not being Implemented - Attempt reservation after many VMs are deployed: Fails due to VMs being outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change the VM's IP - Attempt reservation after first VM is deployed: Either succeeds, or fails if the first VMs IP is outside of the reserved CIDR. How can we fix this without hacking work arounds into the deployment logic? (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that IP, if it already exists deploy it wherever.) Thank You, Logan Barfield Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Hi Marcus, I'll give that a shot. I didn't know if those parameters specified the network CIDR or the guest CIDR. Thank You, Logan Barfield Tranquil Hosting On Mon, Oct 6, 2014 at 3:15 PM, Marcus shadow...@gmail.com wrote: Do startip and endip createNetwork parameters not work for that (when creating the network? That should carve out a subset of the network for cloudstack use and leave the rest untouched. On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com wrote: We have decided internally to set up a CIDR reservation with all new accounts to give us the ability to easily attach dedicated hosts to existing VM networks. We were thinking it would be easier to set up the reservation before deploying VMs. Setting up reservation after the fact can get complicated if a VM happens to be outside the intended reservation range. The issue we're having is that reservation is not allowed until the network is in the Implemented state (i.e. after the first VM is deployed). Why is reservation not allowed upon initial network creation? If we try to apply reservation after the first VM is online the command will fail occasionally because the first VM is deployed outside the CIDR range. Example: Guest Net: 10.1.1.0/24 Reserved CIDR: 10.1.1.0/25 - Attempt reservation before deploying a VM: Fails due to network not being Implemented - Attempt reservation after many VMs are deployed: Fails due to VMs being outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change the VM's IP - Attempt reservation after first VM is deployed: Either succeeds, or fails if the first VMs IP is outside of the reserved CIDR. How can we fix this without hacking work arounds into the deployment logic? (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that IP, if it already exists deploy it wherever.) Thank You, Logan Barfield Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Specifying IPs doesn't work, and in the network details I see that specifyipranges is set to false. I should probably note that this is using Advanced Networking with an Isolated Guest Network. Thank You, Logan Barfield Tranquil Hosting On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield lbarfi...@tqhosting.com wrote: Hi Marcus, I'll give that a shot. I didn't know if those parameters specified the network CIDR or the guest CIDR. Thank You, Logan Barfield Tranquil Hosting On Mon, Oct 6, 2014 at 3:15 PM, Marcus shadow...@gmail.com wrote: Do startip and endip createNetwork parameters not work for that (when creating the network? That should carve out a subset of the network for cloudstack use and leave the rest untouched. On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com wrote: We have decided internally to set up a CIDR reservation with all new accounts to give us the ability to easily attach dedicated hosts to existing VM networks. We were thinking it would be easier to set up the reservation before deploying VMs. Setting up reservation after the fact can get complicated if a VM happens to be outside the intended reservation range. The issue we're having is that reservation is not allowed until the network is in the Implemented state (i.e. after the first VM is deployed). Why is reservation not allowed upon initial network creation? If we try to apply reservation after the first VM is online the command will fail occasionally because the first VM is deployed outside the CIDR range. Example: Guest Net: 10.1.1.0/24 Reserved CIDR: 10.1.1.0/25 - Attempt reservation before deploying a VM: Fails due to network not being Implemented - Attempt reservation after many VMs are deployed: Fails due to VMs being outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change the VM's IP - Attempt reservation after first VM is deployed: Either succeeds, or fails if the first VMs IP is outside of the reserved CIDR. How can we fix this without hacking work arounds into the deployment logic? (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that IP, if it already exists deploy it wherever.) Thank You, Logan Barfield Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Here's an example:
create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
endip=10.10.10.110
This results in a 10.10.10.0/24 network created in this vpc, with
cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in a
VPC, but it should work the same for any guest network.seqselect * from
{
network: {
account: admin,
acltype: Account,
broadcastdomaintype: Vxlan,
broadcasturi: vxlan://10124,
canusefordeploy: true,
cidr: 10.10.10.0/24,
displaynetwork: true,
displaytext: testnet,
dns1: 199.58.198.240,
domain: ROOT,
domainid: d86c4370-bbdf-11e2-8bb5-52540014c04d,
gateway: 10.10.10.1,
id: 97b72d89-d81b-4582-a049-469dc42ad806,
ispersistent: true,
issystem: false,
name: testnet,
netmask: 255.255.255.0,
networkdomain: cs2cloud.internal,
networkofferingavailability: Optional,
networkofferingconservemode: false,
networkofferingdisplaytext: customer internal networks,
networkofferingid: 82c67af0-f92e-479d-b1b4-8732abeef9b7,
networkofferingname: VPC Private Without Load Balancer,
physicalnetworkid: 51617cd5-4715-495d-8931-f5d56e2af2bc,
related: 97b72d89-d81b-4582-a049-469dc42ad806,
restartrequired: false,
specifyipranges: false,
state: Implemented,
strechedl2subnet: false,
tags: [],
traffictype: Guest,
type: Isolated,
vlan: 10124,
vpcid: 7276bcca-469c-4d23-9dd1-3391e964c453,
zoneid: 5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4,
zonename: testzone
}
}
On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Specifying IPs doesn't work, and in the network details I see that
specifyipranges is set to false.
I should probably note that this is using Advanced Networking with an
Isolated Guest Network.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Hi Marcus,
I'll give that a shot. I didn't know if those parameters specified the
network CIDR or the guest CIDR.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:15 PM, Marcus shadow...@gmail.com wrote:
Do startip and endip createNetwork parameters not work for that (when
creating the network? That should carve out a subset of the network for
cloudstack use and leave the rest untouched.
On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
We have decided internally to set up a CIDR reservation with all new
accounts to give us the ability to easily attach dedicated hosts to
existing VM networks.
We were thinking it would be easier to set up the reservation before
deploying VMs. Setting up reservation after the fact can get
complicated
if a VM happens to be outside the intended reservation range.
The issue we're having is that reservation is not allowed until the
network
is in the Implemented state (i.e. after the first VM is deployed).
Why is reservation not allowed upon initial network creation? If we
try to
apply reservation after the first VM is online the command will fail
occasionally because the first VM is deployed outside the CIDR range.
Example:
Guest Net: 10.1.1.0/24
Reserved CIDR: 10.1.1.0/25
- Attempt reservation before deploying a VM: Fails due to network not
being
Implemented
- Attempt reservation after many VMs are deployed: Fails due to VMs
being
outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work
to
change the VM's IP
- Attempt reservation after first VM is deployed: Either succeeds, or
fails
if the first VMs IP is outside of the reserved CIDR.
How can we fix this without hacking work arounds into the deployment
logic?
(ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM
on
that IP, if it already exists deploy it wherever.)
Thank You,
Logan Barfield
Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Hmm, well that used to work, but I just tried it with a 4.4 release and it
completely ignored the startip and endip parameters. I know at one point
there was a db entry allocated for every ip in the range. It was not a good
way to keep the info (large networks == lots of entries), so it may have
been refactored out recently and as a result this may no longer work. Just
speculation.
On Mon, Oct 6, 2014 at 2:00 PM, Marcus shadow...@gmail.com wrote:
Here's an example:
create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
endip=10.10.10.110
This results in a 10.10.10.0/24 network created in this vpc, with
cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in a
VPC, but it should work the same for any guest network.seqselect * from
{
network: {
account: admin,
acltype: Account,
broadcastdomaintype: Vxlan,
broadcasturi: vxlan://10124,
canusefordeploy: true,
cidr: 10.10.10.0/24,
displaynetwork: true,
displaytext: testnet,
dns1: 199.58.198.240,
domain: ROOT,
domainid: d86c4370-bbdf-11e2-8bb5-52540014c04d,
gateway: 10.10.10.1,
id: 97b72d89-d81b-4582-a049-469dc42ad806,
ispersistent: true,
issystem: false,
name: testnet,
netmask: 255.255.255.0,
networkdomain: cs2cloud.internal,
networkofferingavailability: Optional,
networkofferingconservemode: false,
networkofferingdisplaytext: customer internal networks,
networkofferingid: 82c67af0-f92e-479d-b1b4-8732abeef9b7,
networkofferingname: VPC Private Without Load Balancer,
physicalnetworkid: 51617cd5-4715-495d-8931-f5d56e2af2bc,
related: 97b72d89-d81b-4582-a049-469dc42ad806,
restartrequired: false,
specifyipranges: false,
state: Implemented,
strechedl2subnet: false,
tags: [],
traffictype: Guest,
type: Isolated,
vlan: 10124,
vpcid: 7276bcca-469c-4d23-9dd1-3391e964c453,
zoneid: 5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4,
zonename: testzone
}
}
On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Specifying IPs doesn't work, and in the network details I see that
specifyipranges is set to false.
I should probably note that this is using Advanced Networking with an
Isolated Guest Network.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Hi Marcus,
I'll give that a shot. I didn't know if those parameters specified the
network CIDR or the guest CIDR.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:15 PM, Marcus shadow...@gmail.com wrote:
Do startip and endip createNetwork parameters not work for that (when
creating the network? That should carve out a subset of the network for
cloudstack use and leave the rest untouched.
On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
We have decided internally to set up a CIDR reservation with all new
accounts to give us the ability to easily attach dedicated hosts to
existing VM networks.
We were thinking it would be easier to set up the reservation before
deploying VMs. Setting up reservation after the fact can get
complicated
if a VM happens to be outside the intended reservation range.
The issue we're having is that reservation is not allowed until the
network
is in the Implemented state (i.e. after the first VM is deployed).
Why is reservation not allowed upon initial network creation? If we
try to
apply reservation after the first VM is online the command will fail
occasionally because the first VM is deployed outside the CIDR range.
Example:
Guest Net: 10.1.1.0/24
Reserved CIDR: 10.1.1.0/25
- Attempt reservation before deploying a VM: Fails due to network not
being
Implemented
- Attempt reservation after many VMs are deployed: Fails due to VMs
being
outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work
to
change the VM's IP
- Attempt reservation after first VM is deployed: Either succeeds, or
fails
if the first VMs IP is outside of the reserved CIDR.
How can we fix this without hacking work arounds into the deployment
logic?
(ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM
on
that IP, if it already exists deploy it wherever.)
Thank You,
Logan Barfield
Tranquil Hosting
Re: Reserved Guest VM CIDR Question
Yeah, that was my result as well.
It seems like you should be able to specify a 'guestcidr' when creating the
network, or at least with 'updateNetwork' without the network being in the
Implemented state. I'm sure there's a reason for it being that way, but
it doesn't make much intuitive sense.
Unless I'm missing the point of the IP reservation feature this issue is
probably just the result of bad design decisions somewhere.
Does anyone know why it's required for the network to be Implemented
before specifying the reserved CIDR? Does Implemented indicate that the
Virtual Router has been created/online, or that a VM has been deployed on
the network? If it's just a Virtual Router check, is there a way to force
the Virtual Router to be created when creating the network, instead of
having it deploy when the first VM is created?
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 4:04 PM, Marcus shadow...@gmail.com wrote:
Hmm, well that used to work, but I just tried it with a 4.4 release and it
completely ignored the startip and endip parameters. I know at one point
there was a db entry allocated for every ip in the range. It was not a good
way to keep the info (large networks == lots of entries), so it may have
been refactored out recently and as a result this may no longer work. Just
speculation.
On Mon, Oct 6, 2014 at 2:00 PM, Marcus shadow...@gmail.com wrote:
Here's an example:
create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
endip=10.10.10.110
This results in a 10.10.10.0/24 network created in this vpc, with
cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in
a
VPC, but it should work the same for any guest network.seqselect * from
{
network: {
account: admin,
acltype: Account,
broadcastdomaintype: Vxlan,
broadcasturi: vxlan://10124,
canusefordeploy: true,
cidr: 10.10.10.0/24,
displaynetwork: true,
displaytext: testnet,
dns1: 199.58.198.240,
domain: ROOT,
domainid: d86c4370-bbdf-11e2-8bb5-52540014c04d,
gateway: 10.10.10.1,
id: 97b72d89-d81b-4582-a049-469dc42ad806,
ispersistent: true,
issystem: false,
name: testnet,
netmask: 255.255.255.0,
networkdomain: cs2cloud.internal,
networkofferingavailability: Optional,
networkofferingconservemode: false,
networkofferingdisplaytext: customer internal networks,
networkofferingid: 82c67af0-f92e-479d-b1b4-8732abeef9b7,
networkofferingname: VPC Private Without Load Balancer,
physicalnetworkid: 51617cd5-4715-495d-8931-f5d56e2af2bc,
related: 97b72d89-d81b-4582-a049-469dc42ad806,
restartrequired: false,
specifyipranges: false,
state: Implemented,
strechedl2subnet: false,
tags: [],
traffictype: Guest,
type: Isolated,
vlan: 10124,
vpcid: 7276bcca-469c-4d23-9dd1-3391e964c453,
zoneid: 5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4,
zonename: testzone
}
}
On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Specifying IPs doesn't work, and in the network details I see that
specifyipranges is set to false.
I should probably note that this is using Advanced Networking with an
Isolated Guest Network.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
Hi Marcus,
I'll give that a shot. I didn't know if those parameters specified
the
network CIDR or the guest CIDR.
Thank You,
Logan Barfield
Tranquil Hosting
On Mon, Oct 6, 2014 at 3:15 PM, Marcus shadow...@gmail.com wrote:
Do startip and endip createNetwork parameters not work for that (when
creating the network? That should carve out a subset of the network
for
cloudstack use and leave the rest untouched.
On Oct 6, 2014 12:57 PM, Logan Barfield lbarfi...@tqhosting.com
wrote:
We have decided internally to set up a CIDR reservation with all
new
accounts to give us the ability to easily attach dedicated hosts to
existing VM networks.
We were thinking it would be easier to set up the reservation
before
deploying VMs. Setting up reservation after the fact can get
complicated
if a VM happens to be outside the intended reservation range.
The issue we're having is that reservation is not allowed until the
network
is in the Implemented state (i.e. after the first VM is
deployed).
Why is reservation not allowed upon initial network creation? If
we
try to
apply reservation after the first VM is online the command will
fail
occasionally because the first VM is deployed outside the CIDR
RE: Reserved Guest VM CIDR Question
Logan, The reason why reservation is not enabled in create stage is the case of External network devices. When using external devices like NetScaler, CloudStack will not have a 'real' cidr unless the network has been implemented. So a cidr like /24 used at time of create may turn to /20 when the network has been implemented and then it make no sense for reservation in initial stage. What I will suggest is to create a network offering with 'Persistent' as true. So your network will be implemented when you create it and VR will be up. Once the network has been implemented you can apply reservation. Thanks, Saksham -Original Message- From: Logan Barfield [mailto:lbarfi...@tqhosting.com] Sent: Tuesday, October 7, 2014 12:27 AM To: dev@cloudstack.apache.org Subject: Reserved Guest VM CIDR Question We have decided internally to set up a CIDR reservation with all new accounts to give us the ability to easily attach dedicated hosts to existing VM networks. We were thinking it would be easier to set up the reservation before deploying VMs. Setting up reservation after the fact can get complicated if a VM happens to be outside the intended reservation range. The issue we're having is that reservation is not allowed until the network is in the Implemented state (i.e. after the first VM is deployed). Why is reservation not allowed upon initial network creation? If we try to apply reservation after the first VM is online the command will fail occasionally because the first VM is deployed outside the CIDR range. Example: Guest Net: 10.1.1.0/24 Reserved CIDR: 10.1.1.0/25 - Attempt reservation before deploying a VM: Fails due to network not being Implemented - Attempt reservation after many VMs are deployed: Fails due to VMs being outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change the VM's IP - Attempt reservation after first VM is deployed: Either succeeds, or fails if the first VMs IP is outside of the reserved CIDR. How can we fix this without hacking work arounds into the deployment logic? (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that IP, if it already exists deploy it wherever.) Thank You, Logan Barfield Tranquil Hosting
