@Steve: yeah, the MAC I see in the DHCP REQUEST is the same that shows up in the DHCP Server (quantum-server)
@Peter: Hmm, should I enable anything in special in 2012, that I do not have to in 2008 R2 ? Because apparently I'm still having the same issue... (I just setup another host with Hyper-V 2012) Thank you -- Bruno Oliveira Developer, Software Engineer On Wed, Jun 5, 2013 at 10:46 PM, Peter Pouliot <ppoul...@microsoft.com> wrote: > First off you should be using hyper-v from 2012 server. 2008 only supports > flat networking as of the last time I used it. All active development is > geared towards 2012 hyper-v. Functionality for is minimal for 2008 which > is also in the wmiv1 namespace. The legacy/original wmiv1 is basically > being replaced by wmiv2 for Havana. > > Try hyper-v server 2012, we give it away for free. > > And use that instead of 2008 hyper-v. You will have better results and 90% > more functionality. > > P > > > > > Sent from my Verizon Wireless 4G LTE Smartphone > > > > -------- Original message -------- > From: Steve Heistand <steve.heist...@nasa.gov> > Date: 06/05/2013 7:08 PM (GMT-05:00) > To: Bruno Oliveira <brunnop.olive...@gmail.com> > Cc: OpenStack <openstack@lists.launchpad.net> > Subject: Re: [Openstack] [HyperV][Quantum] Quantum dhcp agent not working > for Hyper-V > > > is the MAC addr coming from the hyper-v on the dhcp request the same one the > dhcp-agent is > expecting? > > s > > > On 06/05/2013 03:23 PM, Bruno Oliveira wrote: >> Hello all, >> >> Guys, there's something regarding quantum that we've been hitting our >> heads >> against a wall for a few weeks, but can't figure out. Can you please >> take a look? >> >> Here's the scenario: >> >> We currently have a single-node devstack build, running nova (compute), >> glance, >> quantum (with OpenVSwitch), swift and cinder -- besides keystone and >> ceilometer. >> >> On that very same machine, our kvm hypervisor is running. Everything >> works like a charm with it: dhcp, magic_ip (169.254.169.254), reaching >> in/outside networks, etc. >> >> >> Now for the issue: there's another host running hyper-v 2008 r2, and on >> top of that, we got Cloudbase's (cloudbase.it) Compute Driver for Hyper-V. >> That way, we're successfully being able to create VMs for it (Hyper-V), >> BUT... >> >> Even though there's a virtual switch in there (hyper-v), the network for >> the >> instances are not working -> the instances are not being assigned with an >> IP from quantum-dhcp UNLESS I use the FLAT NETWORK model to assign >> a public ip for each of them. So... >> >> 1. Is there a must to have ANOTHER quantum-server just for hyper-v nodes >> taking that I do not want to use Flat Network ? >> (by another, I mean one besides the working one I have for KVM) >> >> 2. In our case, we're intending to have NAT IPs for each of the instance >> we >> have running on hyper-v, not public_ips directly assigned to them, is >> it possible? >> >> After all the testing and research we did, we concluded that we CAN >> see the DHCP broadcast coming from hyper-v (via tcpdump'ing on >> any interface that is on the same subnet) but the DHCP response/reply >> is not working. >> >> Note: "$quantum agent-list" DOES list the quantum-agent from kvm >> but not from hyper-v >> >> Does anyone have any guesses or suggestions of what we could >> possibly try ? >> >> >> Thank you a lot >> >> -- >> >> Bruno Oliveira >> Developer, Software Engineer >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > -- > ************************************************************************ > Steve Heistand NASA Ames Research Center > SciCon Group Mail Stop 258-6 > steve.heist...@nasa.gov (650) 604-4369 Moffett Field, CA 94035-1000 > ************************************************************************ > "Any opinions expressed are those of our alien overlords, not my own." > > # For Remedy # > #Action: Resolve # > #Resolution: Resolved # > #Reason: No Further Action Required # > #Tier1: User Code # > #Tier2: Other # > #Tier3: Assistance # > #Notification: None # > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
