Lucian Petrut's profile - activity

Hi,

This is an issue that has been fixed right after the Mitaka MSI has been released. Here you have the according bug report and bug fix: https://bugs.launchpad.net/compute-hy... https://github.com/openstack/compute-...

We're going to release a new Mitaka MSI when releasing Newton (most probably next week), so you could either wait for that or apply this fix.

I'm sorry for the inconvenience.

Regards, Lucian Petrut

Hi, this issue has been fixed on the master branch by the following change: https://review.openstack.org/#/c/371685/

We'll backport this fix to Mitaka as soon as possible.

So you have qcow2 images stored on SMB shares, attaching them to KVM instances, right? In that case, you may want to use the Cinder Linux SMB driver. In the next Cinder release, we will support qcow2/raw images with the Windows SMB driver as well.

The Windows SMB driver supports only vhd/x images for storing the volumes. I think you are creating a volume using a Glance image, right? In that case, previously, it was converting the qcow2 image to a vhd/x image. Since this is a time consuming task, especially if done often and having large images, we now expect the provided image to be a vhd/x image.

You could convert the image to vhd or vhdx before submitting it to Cinder.

I was able to replicate your issue and submitted a new patch. Please let me know how this works for you: Downstream Cinder Liberty patch: https://github.com/cloudbase/cinder/commit/c57b85ea06d899f2a6d5fb6ecc37f0da3b6fca6b os-win patch: https://review.openstack.org/#/c/280640/

What SMB share backend are you guys using? Is it a Windows share, Samba share or a NAS based one? I'm wondering if the locks are handled properly by the share backend, or perhaps it's the share mode flags. Either way, I'm looking further into this.

Hi,

When a live migration is performed, the destination host will initialize the connection to all the volumes connected to the instance. Cinder plays a role in this process, ensuring that the volume can be accessed by the destination host, providing the relevant connection information. In this case, Cinder will attempt to open the image to retrieve the format.

Now, this seems to cause your issue. It appears that in some environments, the access mask is not handled properly and we are unable to open in-use images. The good news is that I've just sent a fix for this:

https://review.openstack.org/#/c/275102 (os-win, used by Cinder M) https://github.com/cloudbase/cinder/t... (downstream Cinder Liberty repo)

Unfortunately, the Cinder policy related to backports would not allow us to send this fix on the upstream Libery branch as they only accept backporting security bug fixes. Anyway, you can use our downstream repo provided above.

Please let me know if this fixes your issue. We'll provide an updated MSI soon.

Regards, Luci

Can you please make sure that the hyperv ML2 mechanism driver is enabled on your Neutron controller? Note that networking-hyperv is required.

Can you please make sure that the hyperv ML2 mechanism driver is enabled on your Neutron controller? Note that networking-hyperv is required.

Please provide the cloudbase-init logs as well, just to make sure you're not having this issue: https://bugs.launchpad.net/cloudbase-....

Are you sure that the image is ok? Can you please paste the output of the following commands? (preferably using pastebin)

qemu-img info <unarchived_image_path>

qemu-img check <unarchived_image_path>

domainname=$(nova show <instance_display_name> | grep instancename | awk '{print $4}')

virsh dumpxml $domain_name

This is not actually a bug. If the same endpoint is available in multiple regions, you must specify which region should be used.

One of the ways of doing this is by using the endpointtemplate config option, which you already did. Also, you may pass the region name using --os-region-name when using the attach command or you may put OSREGION_NAME variable in env.

Regards, Lucian