Hi Matthew,

First of all, I'm pleased that the VDI community is now so well connected via the Matrix room to support each other :)

Regarding your problem, it looks to me more like an access issue from the Bumblebee application to the OpenStack services data. The Bumblebee application cannot query information about your specified security groups.

You can try using the OpenStack client to impersonate a Bumblebee application. To do this, you need to use the --os-auth-url and --os-token command line options to perform authentication via the Bumblebee application credentials. If you can't see any security groups, then it's clearly a permission problem. The next step in this case would be to check the access rules of the application credentials. Otherwise, the problem could be related to an issue in your OpenStack setup.

The detailed settings for the security groups and the CIDR value depends on your intended network architecture. The security groups are used by the OpenStack Neutron service, to automatically manage and deploy your networks and proper routing. The CDIR value should specify a (virtual) network that can also be reached by Bumblebee's guacamole service. New VMs for virtual desktops are then automatically provisioned with a network interface for this network. Therefore, bumblebee has to query the information from the security groups in order to parameterize the creation of the VMs. By default you can use the shared network from the DevStack setup. In production environments, however, you should provide an extra network for the VMs from the VDI in order to maintain isolation for security and to be able to regulate QOS more easily, etc.

By the way, the shared flag of a security group has nothing to do with the network configuration in the first place. This flag just shows whether a security group can be shared with OpenStack projects. See https://docs.openstack.org/neutron/latest/admin/config-rbac.html#how-the-shared-flag-relates-to-these-entries for more information.

Regards,
Manuel

Hi Manuel,

Thank you for your kind response. And yes, I fixed my previous issue and was able to access the Django Admin site like you shared a screenshot. Thank you for sharing that.🥰

Also, I contacted Andy and I'm in the same boat with him in the Matrix Element chat app. I've been contacting your former Freibug Univerisity colleagues from several months ago through Matrix Element room, Dirk, Michael Scherle, etc. They are really supportive. 👍

I'm also planning to collaborate on the project: https://github.com/OpenSourceVDI/osvdi . So this is the pre-development step for me

So at least I want to try to test this bumblebee VDI based on DevStack on my local first, but Andy has also never tested the bumblebee on Devstack yet. I'm a bit sorry to Freiburg colleagues since they are already experienced in this step and they are forwarding to develop VDI that can support 3D rendering so I don't want to take time from them and want to support them as soon as possible after I pass through this step.

For now, I stuck the one issue to create VDI. The issue is when I creating VDI, I got this issue.

I guess there is a problem with setting up the security group. I ran the setup-openstack.sh script by setting CIDR=192.168.174.0/24 and setting the OS_SECGROUPS=bumblebee_desktops.

I'm not sure I did correctly. Could you please let me know what the would be CIDR value in the setup-openstack.sh and OS_SECGROUPS in the env file?

Let me attach some of my current configuration screenshots for references.

Networks:

Security Groups:

bumblebee-desktops security group detail:

Security Group and keypair values:

bumblebee-desktop Security Group detail:

Env file:

I'd appreciate it if you could kindly reply to my email again.

Please keep in touch.

Much appreciated.

Matthew

On Thu, Mar 28, 2024 at 5:58 AM Manuel Bentele <development@manuel-bentele.de> wrote:

Hi Matthew,

I fixed the above issue. The issue was happening because when trying to create an instance through the nova client, input parameters(security_groups and key_name) were empty.

Nice to hear that you were able to solve the problem. At some code locations, Bumblebee could still have better error handling ;)

I quickly set up a fresh instance of Bumblebee and can't reproduce your Django admin site access problem. If I use the default settings from the Docker compose .env file and log in with the admin account, an 'Admin' button appears in the menu bar:

If you then click on the 'Admin' button, the Django admin site will load:

There you can then graphically edit the corresponding objects from the Bumblebee data model. For example, here is the mask for changing the Ubuntu Jammy desktop type if you click on 'Desktop types' and then 'jammy':

You can now do the same for the volumes or other objects. Why access to the Django admin site doesn't work for you is a mystery to me. The same also applies to the security groups. So far I have only ever assigned one security group. Perhaps there is still an error due to a bug in the Bumblebee logic if several security groups are specified.

Anyway, I am also fully available on the weekends. I joined in OpenStack VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org) 

So hopefully we can discuss more detail through that room.

Interesting, I haven't heard of that yet. Oh I see that my former colleagues are also active there. I started this project back then: https://github.com/OpenSourceVDI/osvdi. And now it seems that the project is making visible progress.

In the meantime, I no longer have anything to do with the VDI topic due to another job. I just saw your question on the mailing list and thought I could help. I have dealt with Bumblebee in the past and was also in contact with Andy Botting. He is one of the main developers of Bumblebee and reads the OpenStack mailing list from time to time. He is always happy to receive further support for Bumblebee from the community and their feedback. If you have specific questions, you can also contact him directly: Andy Botting <andy@andybotting.com>. Nevertheless, you can also ask my former colleagues from the University of Freiburg in the Matrix room. I put their email addresses in the CC. They can help you too.

Regards,
Manuel

On 26.03.24 07:37, Matthew Swigart wrote:

Hi Manuel, 

I fixed the above issue. The issue was happening because when trying to create an instance through the nova client, input parameters(security_groups and key_name) were empty. So I created a new keypair and added keyname to env, And then I got the security group list by running the "openstack security group list" command.

So I set "bumblebee-desktops" to OS_SECGROUPS in the env file, but I got this issue -Unable to find security_group with name or id 'bumblebee-desktops'

Here is my current env file screenshot:

Do you have any idea how to set the correct OS_SECGROUPS value in the env file? If you already have the correct env file, then please let me know.

Thank you,

Matthew

On Mon, Mar 25, 2024 at 9:45 PM Matthew Swigart <matthew.swigart35@gmail.com> wrote:

Hello Manuel,

Appreciate your kind response. To fix the bad UUID, I updated the flavor field type from UUID to String instead in the Volume class from model.py. Also I created migration for this. So I was able to fix the above issue but after that changes, I got the new error.

Let me attach the screenshot.

Anyway, I am also fully available on the weekends. I joined in OpenStack VDI room Matrix element. (https://matrix.to/#/#opensource-vdi:matrix.org) 

So hopefully we can discuss more detail through that room.

Regards,

Matthew

On Mon, Mar 25, 2024 at 6:00 PM Manuel Bentele <development@manuel-bentele.de> wrote:

Hi Matthew,

I'm glad that my mail was helpful to you.

[...] I tried debugging the value and desktop_type.default_flavor.id value is 2 [...]

This seems to be where the error lies. A decimal value is set, but it is not a valid UUID.

[...] I tried checking the admin URL (/rcsadmin) but I can't see any link to access DB records.) [...]

You are already on the right track. It might be the case that the user does not yet have the appropriate flags in Keycloak to be able to access it. You can double check whether the required attribute "is_staff" is set as stated in the Django documentation (see [3]). This attribute is automatically set in Bumblebee if a user is already assigned the "staff" role in Keycloak. Maybe there is something wrong in the initial setup?

Please let me know your discoveries. I don't have much time at the moment, but towards the end of the week I can set up a fresh instance myself and see if access to the Django admin page still works.

[3] https://docs.djangoproject.com/en/5.0/ref/contrib/admin/#overview

Regards,
Manuel

On 3/25/24 04:36, Matthew Swigart wrote:

Hi Manuel, thank you for your helpful email.

Yes, you are correct, so there is an issue when creating a record in DB from vm_manager>vm_functions>create_vm.py>create_volume>Line 122 [1] (I tried debugging the value and desktop_type.default_flavor.id value is 2) and vm_manager>models.py>Volume class Line 138 [2]

Could you please let me know how to fix the issue in more detail? 

And you said, I can access DB records through the Django admin site, could you please let me know how to do it? (I tried checking the admin URL (/rcsadmin) but I can't see any link to access DB records.)

[1] https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b9372c0152f4/vm_manager/vm_functions/create_vm.py#L122

[2] https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b9372c0152f4/vm_manager/models.py#L138

Regards,

Matthew

On Sun, Mar 24, 2024 at 2:34 PM Manuel Bentele <development@manuel-bentele.de> wrote:

Hi Matthew,

It looks like a UUID is missing or corrupted in the Django data model of Bumblebee while creating a volume record for a new VM.

If we take a look at the model of a Bumblebee volume, we notice that a valid UUID for the flavor field is required (see [1]). During the VM creation, a new volume record is created where the volume's flavor field is set to the resolved UUID of the default flavor from a desktop type (see [2]). Setting an invalid flavor UUID could be the cause here.

When setting up bumblebee, did you specify valid flavor names (existing ones from OpenStack) for all desktop types?

To check the volume records in the database and adjust them if necessary, you can simply use the Django admin site. There you can view the entire data model of Bumblebee and all stored records graphically.

[1] https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b9372c0152f4/vm_manager/models.py#L138
[2] https://github.com/NeCTAR-RC/bumblebee/blob/2201540ba50af98838d9285d4659b9372c0152f4/vm_manager/vm_functions/create_vm.py#L122

Best regards,
Manuel

On 3/24/24 04:29, Matthew Swigart wrote:

Hello,

I'm trying to install the VDI project on my Ubuntu 22.04 LTS Desktop VMware workstation.

So I chose Bumblebee(https://github.com/NeCTAR-RC/bumblebee) and went through several steps like configuring the devstack, installing docker, and Bumblebee project.

And then, I tried to create a virtual desktop from Bumblebee and I got the below error:

ValueError: badly formed hexadecimal UUID string

Attached error screenshot:

Anybody has already experienced a similar issue or does anybody have any idea to solve this problem? Then please help me.

Looking forward to hearing from you.

Much appreciated.

Matthew