roli's profile - activity

Great! Let me know if we can help out with testing.

Hello, Have anybody had the chance to get any experience of Hyper-V together with Ocata yet (Nova, Neutron-Ovs-Agent, Cinder)? Are there any pitfalls to be aware of? Will the Newton-versions of Cloudbase binary components work or would we be better off trying to compile components from scratch based on what's available on https://github.com/openstack/ ?

Best regards Roger

It currently looks like this http://pastebin.com/wmHsJ3VG

Do you know why the neutron-ovs-agent does not add the "normal" flow automatically? Is it possible to configure something to make it do so? Each time the ovs-vswitchd service is restarted I currently have to add it again manually...

Thanks! When enabling the br-ex virtual interface in Windows and setting the VXLAN IP on that interface it works after recabling the interface physically to the "tunnel switch" and also adding the normal flow via `ovs-ofctl add-flow br-ex actions=normal`.

OK, hope that is the problem. I will try to change it when I'm on site on monday and let you know.

As you will see I try to use my Management interface (10.60.11.25) as the source of my VXLAN-tunnels. That's the way our working Linux-computes are set up. The Management interface is not the interface that is VMswitch enabled and connected to br-ex (the VMswitch enabled interface is Tenant).

and flows after the flow was added for br-ex http://pastebin.com/3TyMdt28 The Hyper-V VM now runs on internal IP 192.168.0.15 (external 10.60.12.156) and MAC FA:16:3E:54:CC:E7.

Before adding the br-ex normal flow you suggested http://pastebin.com/S0KQqQ0f http://pastebin.com/SrrWxBsX http://pastebin.com/BCAsUc4r http://pastebin.com/ABijLVBY http://pastebin.com/9d7tNMQq http://pastebin.com/Yri4Beih http://pastebin.com/sBtc1M76 http://pastebin.com/Fy7DTfe7

The Hyper-V host is new and has not been working in the OpenStack environment earlier. It's the first time we try to get HyperV into the system so we probably has made some basic mistake setting it up.

The Linux hypervisors work well with the controllers, instances launched on them can be reached from other VMs and from outside without any problems. Do you know why I get ICMP port unreachable messages from the HyperV host for all incoming VXLAN traffic?

I also tried adding the normal flow to br-ex. I no longer get any drops there. I will try to redo the installation according to the url provided, when I'm back in office and let you know the results.

Thanks for your quick response. I tried removing vxlan_group = 239.1.1.1 and bridge_mappings = physnet1:br-ex. But still it will not open a UDP/4789 listening port for VXLAN. I suppose that will be needed?! Any idea what could be the cause of this?

Thank you so much! That was easy when you knew it. Works just fine when you use openstack image create --file Windows-Server-2016-Standard.vhdx --container-format bare --disk-format vhd --public Windows-Server-2016-Standard-vhdx_as_vhd

Hi, I'm trying to get Nova on Hyper-V to work with vhdx Glance images. The images works well when started on Linux KVM, but on Hyper-V I get the following error in nova.log.

2017-02-21 16:38:18.236 7124 ERROR nova.compute.manager [instance: ca6e66e5-aba3-43c9-8150-9beca16e0d91] nova.exception.InvalidImageFormat: Invalid image format 'vhdx'

I can boot other images in VHD format fine on the same hypervisor. We run Newton release (via Kolla) and use the nova Windows components from https://cloudbase.it/downloads/HyperV...Newton1401.zip. Any idea what could be the cause of this? As far as I understand it vhdx should be supported.

My nova.conf looks like this:

[DEFAULT]
auth_strategy=keystone
image_service=nova.image.glance.GlanceImageService
compute_driver=compute_hyperv.driver.HyperVDriver
network_api_class=nova.network.neutronv2.api.API
volume_api_class=nova.volume.cinder.API
instances_path=C:\OpenStack\Instances
use_cow_images=true
flat_injected=true
mkisofs_cmd=C:\Program Files\Cloudbase Solutions\OpenStack\Nova\bin\mkisofs.exe
verbose=true
allow_resize_to_same_host=true
running_deleted_instance_action=reap
running_deleted_instance_poll_interval=120
resize_confirm_window=5
resume_guests_state_on_host_boot=true
rpc_response_timeout=1800
use_neutron=true
vif_plugging_is_fatal=false
vif_plugging_timeout=60
rpc_backend=rabbit
logdir=C:\OpenStack\Log\
logfile=nova-compute.log
force_config_drive=True
debug = False
transport_url = rabbit://openstack:password@10.60.11.21:5672,openstack:password@10.60.11.22:5672

[oslo_policy]
policy_file=C:\Program Files\Cloudbase Solutions\OpenStack\Nova\etc\policy.json

[oslo_concurrency]
lock_path=C:\OpenStack\Log\

[glance]
debug = False
api_servers=http://10.60.11.21:9292,http://10.60.11.22:9292

[hyperv]
vswitch_name=br-ex
limit_cpu_features=true
config_drive_inject_password=false
qemu_img_cmd=C:\Program Files\Cloudbase Solutions\OpenStack\Nova\bin\qemu-img.exe
config_drive_cdrom=true
dynamic_memory_ratio=1
enable_instance_metrics_collection=false

[rdp]
enabled=true
html5_proxy_base_url=http://10.60.11.25:8000/

[neutron]
url = http://10.60.11.201:9696

auth_strategy=keystone
project_domain_name=Default
project_name=service
user_domain_name=Default
username = neutron
password = password
auth_url = http://10.60.11.201:35357/v3
auth_type=v3password

Do you have any binary packaging of Open vSwitch (preferably 2.6.1) that can be installed on Nanoserver as a compute host, i.e. with Hyper-V? In other words something like your zipped binaries for Nova, Cinder etc.

If not, would it be possible to take the binaries from another Windows installation where your MSI has been installed and move them to the Nanoserver. If so what other steps would be required rather than register the two services for ovsdb and ovswitchd? For example how do I register the Hyper-V Virtual Switch Extension so that it becomes possible to enable?