ADarkDividedGem's profile - activity

After spamming the "list disk" command during the creation of the instance the 1Gig volume does appear briefly as "Disk 9 Offline 1024 MB 1024 MB" but then disappears.

The volume.log (http://paste.openstack.org/show/594131/) reports "Attach volume completed successfully" followed by "Detach volume completed successfully." which suggests its attaching the volume then detaching it for some reason?

The SAN Policy is already set to "Offline All", I changed it to "Offline Shared" and the problem still exits

Not sure, I use Storage Spaces Direct so I installed v-magine onto a Cluster Shared Volume that communicates between nodes via Server Message Block (SMB) 3 and 10GbE Remote-Direct Memory Access (RDMA) networking. I don't have a SAN (FC or iSCSI) so I am guessing I am using the standard LVM cinder?

After updating C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python27\Lib\site-packages\os_win\ to the latest version from GitHub, restarted the Nova Compute service and it worked.

One of the changes prevents the code from trying to fetch information from unsupported FC HBA adapters which in this case was my LSI SAS 3008 controller found on my Gigabyte MD80-TM0 Motherboard. This means the following warning found in the nova-compute.log file no longer causes issues further up the call stack:

Could not retrieve FC HBA ports for adapter: com.lsi-GBT SAS3008-0. Exception: Executing Win32 API function HBA_GetAdapterAttributes failed. Error code: 2. Error message: The system cannot find the file specified.

There is also a Mellanox ConnectX-3 Pro on the server which is used by Storage Spaces Direct to communicate between the servers.

There was also an update to VLAN trunk mode which might have also helped since openstack-controller-mgmt-ext and openstack-controller-ext both have the VLAND ID set to 10.

Turns out I needed to run the following on the HV1 host

diskpart san policy=OfflineAll exit

After a fresh install of v-magine (2016.2.0.0) on a hyper-converged deployment with Windows Server 2016 I tried to launch an instance of the "cirros" image but it failed with the common error message:

No valid host was found. There are not enough hosts available.

After ensuring nova service-list listed the "nova-compute" as "enabled" and "up" for my host (HV1) I looked at the /var/logs/nova-conductor.log which reported an error in nova.scheduler.utils

RescheduledException: Build of instance bde11dbc-e5a3-4635-89a4-034513f8efb5 was re-scheduled: <x_wmi: Array item cannot be NULL >

This exception was then repeated in the C:\OpenStack\Log\nova-compute.log log file which showed there were some issues with attaching the volume to the instance:

Unable to attach volume to instance instance-00000001
Traceback (most recent call last):
  File "C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\nova\volumeops.py", line 115, in attach_volume
    disk_bus=disk_bus)
  File "C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\hyperv\nova\volumeops.py", line 281, in attach_volume
    serial=serial)
  File "C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\os_win\utils\compute\vmutils.py", line 496, in attach_volume_to_controller
    diskdrive.HostResource = [mounted_disk_path]
  File "C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python27\lib\site-packages\wmi\__init__.py", line 111, in func_wrapper
    raise x_wmi(err_msg, com_ex)
x_wmi: <x_wmi: Array item cannot be NULL >

It works when I create an instance without a volume which suggests there is something wrong with volume creation. I installed v-magine onto a Cluster Shared Volume that communicates between nodes via Server Message Block (SMB) 3 and 10GbE Remote-Direct Memory Access (RDMA) networking. I don't have a SAN (FC or iSCSI).

The full log files can be found here nova-conductor.log and here nova-compute.log any idea what might be going wrong?

At the moment the v-magine ks.template file installs OpenStack with US language and keyboard layout and the Bucharest timezone:

lang en_US.UTF-8
keyboard --vckeymap=us --xlayouts='us'
timezone --utc Europe/Bucharest

It would be good if the installer could detect the language, keyboard layout and time zone from the Windows environment or at least be able to choose it from a list of options.

Turns out it was a DNS issue, performing a `nslookup` on raw.githubusercontent.com returned the wrong IP resulting in a bad SSL handshake. After adding Google's DNS Server to Hyper-V it resolved correctly http://paste.openstack.org/show/584593/ and v-magine installed correctly without further errors

After downloading and installing the latest version of v-magine and at the end of the installation I got a simple error screen with no further information other than an error occurred. Looking at the v-magine.log file shows some error messages e.g.

2016-10-05 17:34:46,612 WARNING logging warning 1612 2140 AsyncLoopThread Exception occurred, retrying: [Errno socket error] [Errno 1] ssl.c:510: error:140773E8:SSL routines:SSL23GETSERVERHELLO:reason(1000)

2016-10-05 17:34:46,684 ERROR logging error 1596 2140 AsyncLoopThread [Errno socket error] [Errno 1] ssl.c:510: error:140773E8:SSL routines:SSL23GETSERVERHELLO:reason(1000)

Would someone be able to shed more light on what caused the error?

During the setup of v-magine it would be helpful to be able to specify an internal or private switch as an "External virtual switch". Currently my external switch connects to my router provided by my ISP which has limited functionality. To get round this I have created an internal network that connects to my physical router through a virtual host acting as router running pfSense

When running the v-magine installer it fails on the following error:

Loading mirror speeds from cached hostfile
* base: mirror.sov.uk.goscomb.net
* extras: mirrors.melbourne.co.uk
* updates: centos.serverspace.co.uk
Resolving Dependencies
--> Running transaction check
---> Package centos-release-openstack-mitaka.noarch 0:1-2.el7.centos will be updated
---> Package centos-release-openstack-mitaka.noarch 0:1-5.el7 will be an update
--> Processing Dependency: centos-release-ceph-hammer for package: centos-release-openstack-mitaka-1-5.el7.noarch
---> Package mariadb-libs.x8664 1:5.5.50-1.el72 will be updated
---> Package mariadb-libs.x8664 1:10.1.12-4.el7 will be an update
--> Processing Dependency: mariadb-common(x86-64) = 1:10.1.12-4.el7 for package: 1:mariadb-libs-10.1.12-4.el7.x8664
--> Running transaction check
---> Package centos-release-ceph-hammer.noarch 0:1.0-5.el7.centos will be installed
---> Package mariadb-common.x8664 1:10.1.12-4.el7 will be installed
--> Processing Dependency: /etc/my.cnf for package: 1:mariadb-common-10.1.12-4.el7.x8664
--> Running transaction check
---> Package mariadb-config.x8664 1:10.1.12-4.el7 will be installed
---> Package mariadb-libs.x8664 1:5.5.50-1.el72 will be updated
---> Package mariadb-libs.x8664 1:5.5.50-1.el7_2 will be updated
--> Processing Conflict: centos-release-ceph-jewel-1.0-1.el7.centos.noarch conflicts centos-release-ceph < 10.2
--> Finished Dependency Resolution
Error: centos-release-ceph-jewel conflicts with centos-release-ceph-hammer-1.0-5.el7.centos.noarch
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest