Re: [Openstack] Default rules for the 'default' security group
I'm very interested in this, we run essex and have a very bad workaround for this currently, but it would be great to be able to do this (set default rules for the default security group). Boris De : openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net [mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net] De la part de Yufang Zhang Envoyé : 23 août 2012 08:43 À : openstack@lists.launchpad.net Objet : [Openstack] Default rules for the 'default' security group Hi all, Could I ask how to set the default rules for the 'default' security group for all the users in openstack? Currently, the 'default' security group has no rule by default, thus newly created instances could only be accessed by instances from the same group. Is there any method to set default rules(such as ssh or icmp) for the 'default' security group for all users in openstack, so that I don't have to remind the new users to modify security group setting the fist time they logged into openstack and create instances? I have ever tried HP could which is built on openstack, they permit ssh or ping to the instances in the 'default' security group. Best Regards. Yufang ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] What is the most commonly used Hypervisor and toolset combination?
That would be great Jim, I've built a cloud that uses CentOS+libvirt+Xen 4.1.3 to do GPU passthrough and I just love to be able to use libvirt with Xen, this setup makes a lot of sense to me since our main, bigger cloud is the standard libvirt+KVM, using libvirt across the board is great for us. I'm following your work closely, the GPU cloud is still using libvirt+xend but when I move to Xen 4.2 my understanding is that I will need libvirt+xl (xenlight) so I guess there's still some work to be done in libvirt there... The reason I want to move to Xen 4.2 is the GPU passthrough of NVIDIA GPUs... currently, with Xen 4.1.3, I successfully passthrough ATI GPUs only. Boris -Message d'origine- De : openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net [mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net] De la part de Jim Fehlig Envoyé : 18 juillet 2012 17:56 À : John Garbutt Cc : openstack@lists.launchpad.net Objet : Re: [Openstack] What is the most commonly used Hypervisor and toolset combination? John Garbutt wrote: To my knowledge, if you want to use Xen, using XCP or XenServer (i.e. using XenAPI driver) is the way to go. If you look at the contributions to the drivers, you can have a good guess at who is using them. I know people are going into production on XenAPI, not heard about Xen+libvirt in production. Having said this, I have seen some fixes to Folsom around Xen + libvirt, I think from SUSE? Yes, I'm slowly working on improving support for xen.org Xen via the libvirt driver and hope to have these improvements in for the Folsom release. Regards, Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] using extra specs
Hi guys,
I currently have a working cloud with a working GPU passthrough setup
(CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to
openstack.
Here is the plan:
1. Create a new instance type (g1.small) with an extra spec like
xpu_arch = radeon
2. Modify the compute side so that nova-compute publishes this new
capability
I'm in between step 1 and step 2, so normally, when I try and launch a VM with
the new instance type, the scheduling should fail since there is no compute
node publishing this capability yet, but the scheduling does go through despite
having the ComputeFilter available.
My understanding is that by having:
scheduler_available_filters=nova.schedulre.filters.standard_filters
scheduler_default_filters=ComputeFilter
The ComputeFilter should try and ensure that the hosts satisfies the extra
specs but the filter is not doing its job since the VM is scheduler and casted
to the compute node although it does not advertise any of the extra spec.
The extra spec is definitely part of the instance_type, I can see it in the
scheduler log:
(TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0',
u'is_public': True, u'deleted_at': None, u'properties': {u'os_type':
u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0,
u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at':
u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb':
2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0,
u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6},
u'instance_properties': {u'vm_state': u'building', u'availability_zone':
(TRUNCATED)
So again, this VM should not be casted to any compute node and the scheduler
should complain about no host having the required capability but it does not...
the VM is instantiated on the one compute node even though it never published
the required capability.
It looks like the ComputeFilter is either not used properly or I'm missing
something. Basically I want the scheduler to fail when I launch the VM before
I start working on step 2.
Any help appreciated.
Boris
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] using extra specs
Joseph,
Yes sorry about the typo I was retyping these lines in the email.
Whatever, the problem seems to be that the Simple Scheduler I'm using is not
running the filters at all, so I now use the filter_scheduler (I'm on essex by
the way) and the filter does its job and filters out the host since it does not
have the extra spec.
Thanks,
Boris
-Message d'origine-
De : Joseph Suh [mailto:j...@isi.edu]
Envoyé : 9 août 2012 12:29
À : Boris-Michel Deschenes
Cc : openstack@lists.launchpad.net
Objet : Re: [Openstack] using extra specs
Boris-Michel,
One thing that I noticed was a typo: schedulre that can cause malfunction. I am
not sure what version you are using, but recently the extra_spec checking is
moved to compute_capabilities_filter.py (ComputeCapabilitiesFilter). As far as
I understand, the current ComputeFilter does not check extra_specs.
Thanks,
Joseph
(w) 703-248-6160
(c) 571-340-2434
(f) 703-812-3712
http://www.east.isi.edu/~jsuh
Information Sciences Institute
University of Southern California
3811 N. Fairfax Drive Suite 200
Arlington, VA, 22203, USA
- Original Message -
From: Boris-Michel Deschenes boris-michel.desche...@ubisoft.com
To: openstack@lists.launchpad.net
Sent: Thursday, August 9, 2012 11:10:15 AM
Subject: [Openstack] using extra specs
Hi guys,
I currently have a working cloud with a working GPU passthrough setup
(CentOS/libvirt/Xen 4.1.2), now I need to work on adding this new resource to
openstack.
Here is the plan:
1. Create a new instance type (g1.small) with an extra spec like “xpu_arch =
radeon”
2. Modify the compute side so that nova-compute publishes this new capability
I’m in between step 1 and step 2, so normally, when I try and launch a VM with
the new instance type, the scheduling should fail since there is no compute
node publishing this capability yet, but the scheduling does go through despite
having the ComputeFilter available.
My understanding is that by having:
scheduler_available_filters=nova.schedulre.filters.standard_filters
scheduler_default_filters=ComputeFilter
The ComputeFilter should try and ensure that the hosts satisfies the extra
specs but the filter is not doing its job since the VM is scheduler and casted
to the compute node although it does not advertise any of the extra spec.
The extra spec is definitely part of the instance_type, I can see it in the
scheduler log:
(TRUNCATED) u'8895af5063b176bef97ab81f076d57f3', u'min_disk': u'0',
u'is_public': True, u'deleted_at': None, u'properties': {u'os_type':
u'windows'}, u'size': 9256562688}, u'instance_type': {u'root_gb': 0,
u'deleted_at': None, u'name': u'g1.small', u'deleted': False, u'created_at':
u'2012-08-08 18:33:29', u'ephemeral_gb': 0, u'updated_at': None, u'memory_mb':
2048, u'vcpus': 1, u'extra_specs': {u'xpu_arch': u'radeon'}, u'swap': 0,
u'rxtx_factor': 1.0, u'flavorid': u'105', u'vcpu_weight': None, u'id': 6},
u'instance_properties': {u'vm_state': u'building', u'availability_zone':
(TRUNCATED)
So again, this VM should not be casted to any compute node and the scheduler
should complain about no host having the required capability but it does not…
the VM is instantiated on the one compute node even though it never published
the required capability.
It looks like the ComputeFilter is either not used properly or I’m missing
something. Basically I want the scheduler to fail when I launch the VM before I
start working on step 2.
Any help appreciated.
Boris
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] SNAT question
Hi guys, I have a question regarding NAT in openstack I have an openstack cloud (FlatDHCP, multi_host=false) with one nova-network node doing the nating. I have noticed that when I ping an external machine from within a VM, on the receiving end I see the IP of the VM (so the outgoing SNAT works properly). I have also noticed that when I ping a VM inside the cloud from a machine outside, the VM sees the external IP of the nova-network node as the source of the ping and not the real IP of the pinger... (this is the problem for me). I looked at the nova-network machine's iptables and I see this: -A nova-network-snat -s 10.0.0.0/8 -j SNAT --to-source 10.129.40.12 So it's basically setting the nova-network node as the source IP for all incoming traffic, in my situation, this prevents an application running inside the cloud to properly identifies the server located outside, currently, the only peer it sees is the nova-network node and not the IP of the server (located outside the cloud) so my application tries to connect to nova-network instead of the server that initiated the connection. Would it be possible to have SNAT work in a way where, when connecting to a VM from outside the cloud, the VM sees the source IP as the real source IP and not the nova-network controller's ip ? Thank you very much Boris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] SNAT question
Thanks everybody, Vish, I think you've got it, but here are some more details about the setup just to be sure we're on the same level: my private network is defined as 172.0.0.0/21 my floating network is defined as 10.129.44.0/22 physical cloud machines (10.129.40.0/24) outside of the cloud, all machine are in the 10 (10.140.x.x for example) Again the problem is that when I ping FROM 10.140.32.235 (outside the cloud) TO 10.129.44.6 (a VM INSIDE the cloud), tcpdump on the VM will show the source address as 10.129.40.12 (nova-network controller) and NOT 10.140.32.235 (the real pinger). I'm not setting up fixed_range and floating_range because I always thought they were just unneeded duplicate config flags for the network config I do with nova-manage (network create and floating create), obviously they are setup on their own at runtime and here are the values taken from the logfiles: fixed_range = 10.0.0.0/8 floating_range = 4.4.4.0/24 So, Vish's theory makes sense, since my external machine (10.140.32.235) included in the filter for SNAT, the packet is modified and nova-network's IP is set as the source... Vish, should I set fixed_range to 10.129.44.0/22 (this is my floating range) so that this SNATTING takes place only when the communication is 100% intra-VMs? I'm just confused because it's called fixed_range and I'm setting it to a floating range... Please advise, thank you Boris De : Vishvananda Ishaya [mailto:vishvana...@gmail.com] Envoyé : 18 juillet 2012 12:04 À : Boris-Michel Deschenes Cc : openstack@lists.launchpad.net Objet : Re: [Openstack] SNAT question Hi Boris, There must be something misconfigured in your setup. Nova network shouldn't be snatting for other vms. Are your machines outside the cloud also in the 10/8 range? if so you should change the setting for fixed_range to something smaller so it doesn't snat for your other machines. For example, in your conf file, you could use: fixed_range = 10.0.0.0/16 and then make sure that your external machines are in the 10.1.0.0/16 range so they don't conflict. Vish On Jul 18, 2012, at 8:25 AM, Boris-Michel Deschenes wrote: Hi guys, I have a question regarding NAT in openstack I have an openstack cloud (FlatDHCP, multi_host=false) with one nova-network node doing the nating. I have noticed that when I ping an external machine from within a VM, on the receiving end I see the IP of the VM (so the outgoing SNAT works properly). I have also noticed that when I ping a VM inside the cloud from a machine outside, the VM sees the external IP of the nova-network node as the source of the ping and not the real IP of the pinger... (this is the problem for me). I looked at the nova-network machine's iptables and I see this: -A nova-network-snat -s 10.0.0.0/8 -j SNAT --to-source 10.129.40.12 So it's basically setting the nova-network node as the source IP for all incoming traffic, in my situation, this prevents an application running inside the cloud to properly identifies the server located outside, currently, the only peer it sees is the nova-network node and not the IP of the server (located outside the cloud) so my application tries to connect to nova-network instead of the server that initiated the connection. Would it be possible to have SNAT work in a way where, when connecting to a VM from outside the cloud, the VM sees the source IP as the real source IP and not the nova-network controller's ip ? Thank you very much Boris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] SNAT question
Thanks again, Could you just tell me why this SNAT rule is there, is it so that VMs can contact other VMs by their floating IP? I know this SNAT rule is there to render something possible but I don't know what. Boris De : Vishvananda Ishaya [mailto:vishvana...@gmail.com] Envoyé : 18 juillet 2012 15:40 À : Boris-Michel Deschenes Cc : openstack@lists.launchpad.net Objet : Re: [Openstack] SNAT question On Jul 18, 2012, at 9:44 AM, Boris-Michel Deschenes wrote: Thanks everybody, Vish, I think you've got it, but here are some more details about the setup just to be sure we're on the same level: my private network is defined as 172.0.0.0/21 my floating network is defined as 10.129.44.0/22 physical cloud machines (10.129.40.0/24) outside of the cloud, all machine are in the 10 (10.140.x.x for example) Again the problem is that when I ping FROM 10.140.32.235 (outside the cloud) TO 10.129.44.6 (a VM INSIDE the cloud), tcpdump on the VM will show the source address as 10.129.40.12 (nova-network controller) and NOT 10.140.32.235 (the real pinger). I'm not setting up fixed_range and floating_range because I always thought they were just unneeded duplicate config flags for the network config I do with nova-manage (network create and floating create), obviously they are setup on their own at runtime and here are the values taken from the logfiles: fixed_range = 10.0.0.0/8 floating_range = 4.4.4.0/24 So, Vish's theory makes sense, since my external machine (10.140.32.235) included in the filter for SNAT, the packet is modified and nova-network's IP is set as the source... Vish, should I set fixed_range to 10.129.44.0/22 (this is my floating range) so that this SNATTING takes place only when the communication is 100% intra-VMs? If by private network you mean the fixed network you created for your vms with nova-manage, then fixed_range should equal or contain your private network, so you could set it to 172.0.0.0/21. If I've misunderstood and your vms are getting fixed ips in the 10.x range, then you should set fixed_range to 10.0.0.0/16 so it excludes the 10.129 addresses. There are separate snat rules automatically created for floating ips, so the fixed range rule is to allow vms to communicate with the outside world via their fixed ip (if they don't have a floating ip assigned yet) Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] floating IP dns question
I don't understand how to use the floating IP dns extension.
OK, I can add a domain for a project but what DNS server should I query
afterwards to resolve the name to an IP?
The dnsmasq server running on my controller seems to only know about the
novalocal domain (which is the private network)
or is it only usable through the API? even to resolve?
GET /v1.1/tenant_id/os-floating-ip-dns/domain/entries/name
# Sample Response:
{ 'dns_entry' :
{ 'ip' : '192.168.53.11',
'type' : 'A',
'domain' : domain,
'name' : name }}
thanks
Boris
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] auto_assign_floating_ip in essex
Hi everybody, I've noticed that the behavior changed in essex regarding automatic assignation of floating ips : * In Diablo, as soon as the instance was spawned, the floating ip was showing in nova and horizon. * In Essex, the instance first spawns and then, later, as much as 60 seconds later the floating IP gets attached. This is not so bad but sometimes, the floating IP never appears, neither in horizon nor nova list. The strange thing is that the IP is there, attached to the interface of the nova-network server and usable, but since it does not appear in nova or horizon, the user will never get to know it. anyone else noticed this problem? I had this problem with AND without multi_host. Boris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] auto_assign_floating_ip in essex
OK' I've found this here which seems to be related (for those who experience the same problem): https://bugs.launchpad.net/nova/+bug/967166 De : openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net [mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net] De la part de Boris-Michel Deschenes Envoyé : 22 mai 2012 17:09 À : openstack@lists.launchpad.net Objet : [Openstack] auto_assign_floating_ip in essex Hi everybody, I've noticed that the behavior changed in essex regarding automatic assignation of floating ips : · In Diablo, as soon as the instance was spawned, the floating ip was showing in nova and horizon. · In Essex, the instance first spawns and then, later, as much as 60 seconds later the floating IP gets attached. This is not so bad but sometimes, the floating IP never appears, neither in horizon nor nova list. The strange thing is that the IP is there, attached to the interface of the nova-network server and usable, but since it does not appear in nova or horizon, the user will never get to know it. anyone else noticed this problem? I had this problem with AND without multi_host. Boris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
