scsi ids with vmware are not correctly used

Bug #1673726 reported by ybaumy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Incomplete
Undecided
Unassigned

Bug Description

i think i have found a bug
when using maas with vmware sdb mostly gets the mbr then when using juju to deploy the VM doesnt boot
because it expects the first hd
it seems that scsi ids are not correctly read by maas or ubuntu

this even happens when i add a new scsi controller in vmware with 1:0:0:0 and add the second disk there.
the first disk is at 0:0:0:0.

summary: - scsi ids in use with vmware are not correctly used
+ scsi ids with vmware are not correctly used
Changed in maas:
status: New → Incomplete
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Christian,

Can you please attach the following:

1. Attach a screenshot of your 'Storage' Section for the said machine
2. Attach the output of 00-maas-07-block-devices.out for the said machine (you can find it in the machine node details page, 'Machine Output' section, 'Commissioning output' in the dropdown).

That said, this sounds like you can easily fix this:

1. Go to the machine details page.
2. Go to the storage section
3. Configure your /other/ disk to be the root disk.

Changed in maas:
milestone: none → 2.2.0
Revision history for this message
ybaumy (christian-setzer) wrote :

somebody opened the same problem and described it better then me. i think its the same.

https://bugs.launchpad.net/maas/+bug/1673724

i already did what you suggested and am on my way trying as soon as the juju controller is rolled out.

Revision history for this message
ybaumy (christian-setzer) wrote :
Download full text (41.0 KiB)

so i changed the boot disk to be sda

then i tried deploying and this happens

curtin: Installation started. (0.1.0~bzr470-0ubuntu1~16.04.1)

  Logical volume "lvroot" successfully removed

  Volume group "vgroot" successfully removed

WARNING: ext4 signature detected on /dev/vgroot/lvroot at offset 1080. Wipe it? [y/n]: n

  Aborted wiping of ext4.

  1 existing signature left on the device.

  Logical volume "lvroot" created.

Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease

Get:2 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]

Get:3 http://archive.ubuntu.com/ubuntu xenial-security InRelease [102 kB]

Get:4 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [496 kB]

Get:5 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [440 kB]

Get:6 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages [8664 B]

Fetched 1149 kB in 2s (490 kB/s)

Reading package lists...

Reading package lists...

Building dependency tree...

Reading state information...

The following additional packages will be installed:

  crda grub-common grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common iw

  libfreetype6 libnl-3-200 libnl-genl-3-200 linux-firmware

  linux-headers-4.4.0-66 linux-headers-4.4.0-66-generic linux-headers-generic

  linux-image-4.4.0-66-generic linux-image-extra-4.4.0-66-generic

  linux-image-generic os-prober thermald wireless-regdb

Suggested packages:

  multiboot-doc grub-emu xorriso desktop-base fdutils linux-doc-4.4.0

  | linux-source-4.4.0 linux-tools

The following NEW packages will be installed:

  crda grub-common grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common iw

  libfreetype6 libnl-3-200 libnl-genl-3-200 linux-firmware linux-generic

  linux-headers-4.4.0-66 linux-headers-4.4.0-66-generic linux-headers-generic

  linux-image-4.4.0-66-generic linux-image-extra-4.4.0-66-generic

  linux-image-generic os-prober thermald wireless-regdb

0 upgraded, 21 newly installed, 0 to remove and 1 not upgraded.

Need to get 110 MB of archives.

After this operation, 472 MB of additional disk space will be used.

Get:1 http://archive.ubuntu.com/ubuntu xenial/main amd64 libfreetype6 amd64 2.6.1-0.1ubuntu2 [316 kB]

Get:2 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 grub-common amd64 2.02~beta2-36ubuntu3.8 [1704 kB]

Get:3 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 grub2-common amd64 2.02~beta2-36ubuntu3.8 [511 kB]

Get:4 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 grub-pc-bin amd64 2.02~beta2-36ubuntu3.8 [888 kB]

Get:5 http://archive.ubuntu.com/ubuntu xenial/main amd64 grub-gfxpayload-lists amd64 0.7 [3658 B]

Get:6 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 grub-pc amd64 2.02~beta2-36ubuntu3.8 [197 kB]

Get:7 http://archive.ubuntu.com/ubuntu xenial/main amd64 libnl-3-200 amd64 3.2.27-1 [52.1 kB]

Get:8 http://archive.ubuntu.com/ubuntu xenial/main amd64 libnl-genl-3-200 amd64 3.2.27-1 [11.2 kB]

Get:9 http://archive.ubuntu.com/ubuntu xenial/main amd64 wireless-regdb all 2015.07.20-1ubuntu1 [9058 B]

Get:10 http://archive.ubuntu.com/ubuntu xenial/main amd64 iw amd64 3.17-1 [63.5 kB]

Get:11 http...

Revision history for this message
ybaumy (christian-setzer) wrote :

i just want to add.

do i have to create a lvm setup now myself? or will there be a fix for this?

i know from experience with SLES11/12 that vmware scsi ids are not correctly displayed. but this is IMO really something that can be fixed. Suse couldnt fix that in years since I made a report for that.

Revision history for this message
ybaumy (christian-setzer) wrote :

the only real workaround for this is. commission the VM's with one disk. then add the second or more for those to use as ceph-osd. then deploy openstack bundle .. then add-unit to those nodes with 2 or more disks.

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Christian,

The issue is not that. The issue is that MAAS makes a default gor which disk should be root. That assumption differs from how it has been configured. I have a patch for this, so if you could test it, add a completely new machine and commission it, and let me know if it works, I would appreciate it!

https://code.launchpad.net/~andreserl/maas/lp1673724/+merge/320165

Revision history for this message
ybaumy (christian-setzer) wrote : Re: [Bug 1673726] Re: scsi ids with vmware are not correctly used

Hi

I'm ybaumy and tested the patch. You know already from me that it works.
Just wanted to answer this email too.

BR

Christian

Am 2017-03-22 15:23, schrieb Andres Rodriguez:
> *** This bug is a duplicate of bug 1673724 ***
> https://bugs.launchpad.net/bugs/1673724
>
> Hi Christian,
>
> The issue is not that. The issue is that MAAS makes a default gor which
> disk should be root. That assumption differs from how it has been
> configured. I have a patch for this, so if you could test it, add a
> completely new machine and commission it, and let me know if it works,
> I
> would appreciate it!
>
> https://code.launchpad.net/~andreserl/maas/lp1673724/+merge/320165
>
> ** This bug has been marked a duplicate of bug 1673724
> [2.2] MAAS sets the last disk (i.e. sdf) as the boot device,
> instead of the first (i.e. sda)
>
> --
> You received this bug notification because you are subscribed to the
> bug
> report.
> https://bugs.launchpad.net/bugs/1673726
>
> Title:
> scsi ids with vmware are not correctly used
>
> Status in MAAS:
> Incomplete
>
> Bug description:
> i think i have found a bug
> when using maas with vmware sdb mostly gets the mbr then when using
> juju to deploy the VM doesnt boot
> because it expects the first hd
> it seems that scsi ids are not correctly read by maas or ubuntu
>
> this even happens when i add a new scsi controller in vmware with
> 1:0:0:0 and add the second disk there.
> the first disk is at 0:0:0:0.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1673726/+subscriptions

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.