Compose virsh machine will not accept positive value for cores or RAM

Bug #2037752 reported by Josh Malone
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Triaged
Medium
Unassigned
maas-ui
Triaged
Medium
Unassigned

Bug Description

When Composing a virsh machine on 3.4.0 RC2, the GUI refuses to accept positive numbers for cores and RAM. An error is displayed with the message:

Error: Ensure this value is less than or equal to 0.

Base OS Release: 22.04
MAAS version: 3.4.0~rc2

Revision history for this message
Josh Malone (jmalone-lancium) wrote :
Revision history for this message
Peter Makowski (petermakowski) wrote :

Hey Josh, I'm having troubles reproducing the issue. Could you please provide additional information:

- Browser name and version
- Steps to reproduce (does it happen every time or you need to follow specific steps to get to the error)

Changed in maas-ui:
assignee: nobody → Peter Makowski (petermakowski)
Revision history for this message
Josh Malone (jmalone-lancium) wrote : Re: [Bug 2037752] Re: Compose virsh machine will not accept positive value for cores or RAM

Sure,

Browser: Chrome Version 117.0.5938.92 (Official Build) (64-bit)
(Also replicated in Firefox 118.0)

* Upgrade to MAAS 3.4.0~rc2 from MAAS 3.4.0~rc1
* Navigate to MAAS (web UI)
* Deploy a machine as a KVM host using Ubuntu 20 as base OS
* In navigation pane, select "Virsh" under "KVM"
* Select machine deployed earlier
* Under "Take action" select "Compose"
* Click "Compose machine" (leaving all values at default)
  ** (Note: Changing values from defaults also triggers the issue)

On Mon, Oct 2, 2023 at 11:21 AM Peter Makowski <email address hidden>
wrote:

> Hey Josh, I'm having troubles reproducing the issue. Could you please
> provide additional information:
>
> - Browser name and version
> - Steps to reproduce (does it happen every time or you need to follow
> specific steps to get to the error)
>
> ** Changed in: maas-ui
> Assignee: (unassigned) => Peter Makowski (petermakowski)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2037752
>
> Title:
> Compose virsh machine will not accept positive value for cores or RAM
>
> Status in MAAS:
> New
> Status in maas-ui:
> New
>
> Bug description:
> When Composing a virsh machine on 3.4.0 RC2, the GUI refuses to accept
> positive numbers for cores and RAM. An error is displayed with the
> message:
>
> Error: Ensure this value is less than or equal to 0.
>
> Base OS Release: 22.04
> MAAS version: 3.4.0~rc2
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/2037752/+subscriptions
>
>

--
*CONFIDENTIALITY NOTICE:* The information in this email may be confidential
and/or privileged. This email is intended to be reviewed by only the
individual or organization named above. If you are not the intended
recipient or an authorized representative of the intended recipient, you
are hereby notified that any review, dissemination or copying of this email
and its attachments, if any, or the information contained herein is
prohibited. If you have received this email in error, please immediately
notify the sender by return email and delete this email from your system.

Revision history for this message
Josh Malone (jmalone-lancium) wrote :

On Mon, Oct 2, 2023 at 11:29 AM Josh Malone <email address hidden> wrote:

> Sure,
>
> Browser: Chrome Version 117.0.5938.92 (Official Build) (64-bit)
> (Also replicated in Firefox 118.0)
>
> * Upgrade to MAAS 3.4.0~rc2 from MAAS 3.4.0~rc1
> * Navigate to MAAS (web UI)
> * Deploy a machine as a KVM host using Ubuntu 20 as base OS
> * In navigation pane, select "Virsh" under "KVM"
> * Select machine deployed earlier
> * Under "Take action" select "Compose"
> * Click "Compose machine" (leaving all values at default)
> ** (Note: Changing values from defaults also triggers the issue)
>

Should also not that it happens every time, no matter what I do. I'm unable
to compose a Virsh VM in MAAS.

-Josh

--
*CONFIDENTIALITY NOTICE:* The information in this email may be confidential
and/or privileged. This email is intended to be reviewed by only the
individual or organization named above. If you are not the intended
recipient or an authorized representative of the intended recipient, you
are hereby notified that any review, dissemination or copying of this email
and its attachments, if any, or the information contained herein is
prohibited. If you have received this email in error, please immediately
notify the sender by return email and delete this email from your system.

Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

The error is looking like it could be coming from an older version of the front-end. Could you open up the browser console and reload the page?

You should see the version being logged similarly to this:

maas-ui 3.5.0 1f6c3f98d764ded2fc2ac11807ccacaff42f3790

Changed in maas-ui:
status: New → Incomplete
Revision history for this message
Josh Malone (jmalone-lancium) wrote :

On Fri, Oct 6, 2023 at 7:45 AM Thorsten Merten <email address hidden>
wrote:

> The error is looking like it could be coming from an older version of
> the front-end. Could you open up the browser console and reload the
> page?
>
> You should see the version being logged similarly to this:
>
> maas-ui 3.5.0 1f6c3f98d764ded2fc2ac11807ccacaff42f3790

Indeed - it appears my client is still loading the maas-ui 3.4.0 front-end.
Shift-reload fails to update it. Completely clearing the browser cache also
leaves me on 3.4.0. I assume something went wrong when I upgraded from ~rc1
to ~rc2? My package list currently has:

root@lmf-storage-1:/home/jbm# dpkg-query -l | grep -i maas
ii maas
 1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all "Metal as a
Service" is a physical cloud and IPAM
ii maas-cli
 1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS client
and command-line interface
ii maas-common
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS server
common files
ii maas-dhcp
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS DHCP server
ii maas-netmon
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 amd64 MAAS Network
Monitor
ii maas-proxy
 1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS Caching
Proxy
ii maas-rack-controller
 1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all Rack
Controller for MAAS
ii maas-region-api
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all Region
controller API service for MAAS
ii maas-region-controller
 1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all Region
Controller for MAAS
ii python3-django-maas
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS server
Django web framework (Python 3)
ii python3-maas-client
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS python API
client (Python 3)
ii python3-maas-provisioningserver
1:3.4.0~rc2-14314-g.53d5ac1f4-0ubuntu1~22.04.1 all MAAS server
provisioning libraries (Python 3)

-Josh

--
*CONFIDENTIALITY NOTICE:* The information in this email may be confidential
and/or privileged. This email is intended to be reviewed by only the
individual or organization named above. If you are not the intended
recipient or an authorized representative of the intended recipient, you
are hereby notified that any review, dissemination or copying of this email
and its attachments, if any, or the information contained herein is
prohibited. If you have received this email in error, please immediately
notify the sender by return email and delete this email from your system.

Revision history for this message
Josh Malone (jmalone-lancium) wrote :

Sorry, maas-ui version reported in console is

maas-ui 3.4.0 5565f5f0f08f03c67ee489d6d49e9f9ec05a186a

Revision history for this message
Josh Malone (jmalone-lancium) wrote :

Still at maas-ui 3.4.0 after reinstall from packages. Probably going to re-install 3.3 at this point since I just need this to work.

Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

we're trying to reproduce it.

Changed in maas-ui:
status: Incomplete → Triaged
importance: Undecided → Medium
milestone: none → 3.4.x
Revision history for this message
Josh Malone (jmalone-lancium) wrote :

So.... I'm starting to think I'm cursed somehow. Uninstalled 3.4. Installed 3.3 from pkgs. Same issue. Unable to compose a virsh machine with same error on RAM and cores (won't accept positive value).

Chrome inspection shows maas-ui 3.3.0 38e85376eea19055a2989dfe28205fd89aa27ec6

root@lmf-storage-1:/home/jbm# dpkg -l | grep maas
ii maas 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS client and command-line interface
ii maas-common 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS server common files
ii maas-dhcp 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS DHCP server
ii maas-proxy 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS Caching Proxy
ii maas-rack-controller 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all Rack Controller for MAAS
ii maas-region-api 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all Region controller API service for MAAS
ii maas-region-controller 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all Region Controller for MAAS
ii python3-django-maas 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all MAAS server provisioning libraries (Python 3)

root@lmf-storage-1:/home/jbm# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

I just learned that -1 are our default values in the database. These get updated once we establish a connection to the virsh host and update to the real numbers.
That said, it's likely a problem with the connection to virsh or the SSH key. Can you try composing the host via the CLI?
You can find instructions here (make sure to switch to CLI): https://maas.io/docs/how-to-manage-vm-hosts#heading--configuration .

Changed in maas-ui:
assignee: Peter Makowski (petermakowski) → Thorsten Merten (thorsten-merten)
Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

Leaving this as medium and adding MAAS as it's possibly not a UI bug but some other problem with the virsh connection (and possibly no a good error message).

Changed in maas:
assignee: nobody → Thorsten Merten (thorsten-merten)
importance: Undecided → Medium
milestone: none → 3.4.x
status: New → Triaged
Revision history for this message
Josh Malone (jmalone-lancium) wrote :

Ah! So, initially, the request failed with:

jbm@lmf-storage-1:~$ maas jbm vm-host compose -k 3
Unable to compose KVM instance in 'kvm-1'. CPU overcommit ratio is 1.0 and there are -8 available resources; 1 requested.Memory overcommit ratio is 1.0 and there are -16384 available resources; 2048 requested.

However, to verify that maas could communicate with the KVM host, I initiated a 'Refresh' from the GUI. After that, both my CLI and Web-UI compose operations now succeed. I know I have 'Refreshed' the KVM host before (since I created my last VM in virt-manager and Refreshed to get MAAS to pick it up). But now the refresh seems to have solved all of my issues.

Not sure how my system got into this state twice (first with 3.4~rc and then with 3.3.latest). Both were installed from packages, after which I discovered/commissioned/deployed an Ubuntu 20 KVM host (same hardware on both installs). According to dpkg.log, no packages have been updated since my 3.3 install on the 6-October.

I'm happy to accept that this was "operator error" if someone has any clue what I might have done wrong. I initially only reported the bug against 3.4~rc as I felt I had found a simple issue in the ~rc2 virsh handling.

Thanks for your help.

-Josh

Revision history for this message
Josh Malone (jmalone-lancium) wrote :

Aaaaaand, it's back:

jbm@lmf-storage-1:~$ maas jbm vm-host compose -k 3 cores=4 memory=8192 "storage=sda:40,sdb:120"
{"cores": ["Ensure this value is less than or equal to 0."], "memory": ["Ensure this value is less than or equal to 0."]}

Also in the GUI (see attached screenshot). At this point, enough time has passed that the automatic sync has run (I can see this in the event log for the KVM host). I suspect that if I "Refresh" the KVM host in the GUI I will be able to compose a machine again.

[Refreshing...]

Yes - now it works again. It appears that something in that automatic sync resets a critical variable.

-Josh

Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

Can you share the MAAS logs in between these occurrences? Maybe this helps understand why it happens. Happy to see that you found a workaround at least.

https://maas.io/docs/reporting-and-reviewing-bugs (note that from 3.4 you can use journalctl to get maas logs)

Revision history for this message
Josh Malone (jmalone-lancium) wrote :

Sure.

Around 14:02 is when I attempted to compose a new VM, resulting in failure. (I made 2 failed attempts). Around 14:03 I initiated the Refresh of the "kvm-1" virsh host. I was then able to successfully compose a new VM. At 14:59 I attempted to compose a new VM and it failed; I made no changes between those timestamps.

Revision history for this message
Chris Johnston (cjohnston) wrote :

I'm seeing this on snap 3.3.4-13189-g.f88272d1e with maas-ui 3.3.0 38e85376eea19055a2989dfe28205fd89aa27ec6

Revision history for this message
Thorsten Merten (thorsten-merten) wrote :

Thanks for the update. I did not find a quick fix for this so I need to properly target it to be picked up.

Changed in maas:
milestone: 3.4.x → 3.5.0
Changed in maas-ui:
milestone: 3.4.x → 3.5.0
Changed in maas:
assignee: Thorsten Merten (thorsten-merten) → nobody
Changed in maas-ui:
assignee: Thorsten Merten (thorsten-merten) → nobody
no longer affects: maas-ui/3.4
Changed in maas:
milestone: 3.5.0 → 3.5.x
Changed in maas-ui:
milestone: 3.5.0 → 3.5.x
Revision history for this message
Amjad Chami (amjad-chami) wrote (last edit ):

Hi, I managed to reproduce this bug manually. On snapped maas, I ran
sudo systemctl restart snap.maas.supervisor
and immediately after tried to compose a new vm. It takes between 90-120 seconds for maas to settle after a restart and for the compose command to work. This was using the cli, not web gui.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.