by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:00
    chessbyte edited #585
  • 13:36
    agrare edited #585
  • 13:25
    miq-bot commented #585
  • 13:25
    miq-bot labeled #585
  • 13:22
    agrare edited #585
  • 13:19
    agrare synchronize #585
  • 13:17
    agrare review_requested #585
  • 13:17
    agrare opened #585
  • May 29 21:07
    simaishi unlabeled #584
  • May 29 21:07
    simaishi labeled #584
  • May 29 21:07
    simaishi commented #584
  • May 29 21:07

    simaishi on jansa

    Merge pull request #584 from ag… (compare)

  • May 29 17:00
    chessbyte labeled #584
  • May 29 17:00
    chessbyte unlabeled #584
  • May 29 16:27

    chessbyte on master

    Add supports terminate feature Merge pull request #584 from ag… (compare)

  • May 29 16:27
    chessbyte closed #584
  • May 29 16:07
    agrare assigned #584
  • May 29 12:41
    miq-bot commented #584
  • May 29 12:41
    miq-bot commented #584
  • May 29 12:36
    agrare labeled #584
samson7point1
@samson7point1
@agrare I don't know if this is related or something else entirely, but when we tested assigning opaque networks to VMs during provisioning, we didn't catch that the NICs were coming up "Disconnected". They were attached to the correct network but not activated. I'm working with the consultants onsite to try to isolate the cause, but I suspect it's at least possible it has something to do with those opaque networks.
Adam Grare
@agrare
can you be more specific about coming up disconnected
samson7point1
@samson7point1
in vCenter the NIC will appear on the VM, but will have a status of "Disconnected".
Adam Grare
@agrare
like miq reports they're disconnected, or on vsphere they're disconnected
can you manually connect them?
samson7point1
@samson7point1
It will have the correct network assigned and everything
I'm trying to get that question answered right now.
Adam Grare
@agrare
it could be that the "start_disconnected" attribute of our guest_devices was set to false for some reason
or it could be that Opaque backing type that I was talking about before
samson7point1
@samson7point1
That's why I mentioned it
I don't have direct access any more, so I'm working vicariously through the consultants onsite.
Okay, it sounds like the customer has decided to call it a day so I'm no going to be able to get anything more from them until Monday.
I'm going to have them try deploying the same template somewhere with a DVS network to see if the opaque networks thing is the common denominator
Adam Grare
@agrare
:+1:
samson7point1
@samson7point1
@agrare So it's monday and the consulants are back onsite. I can confirm that the NICS provisioned in a disconnected state could be connected manually in vCenter.
We're continuing fault isolation.
Adam Grare
@agrare
okay thanks
samson7point1
@samson7point1
Spoke too soon. The customer told us they were able to manually connect but now they're walking that back.
samson7point1
@samson7point1
So it "appeared" to work but eventually failed with "Failed to connect virtual device 'ethernet0'." on the vCenter side.
Adam Grare
@agrare
If they weren't able to fix it without changing the nic then it likely is the backing type issue
samson7point1
@samson7point1
@agrare Okay, this is a doozy, but I think it makes sense. It turns out that when we provision a VM to one of these networks by name, vCenter is creating a new standard network with an identical name and assigning it to the VM.
Adam Grare
@agrare
oh wow
samson7point1
@samson7point1
It just appeared to work.
Adam Grare
@agrare
yeah so we definitely need to change the nic backing
samson7point1
@samson7point1
The funny thing is that if we don't get the name right it doesn't actually work.
Adam Grare
@agrare
that's going to take longer because the type doesn't exist in the broker sdk definition
samson7point1
@samson7point1
It's almost like we stumbled on some kind of bug in the API
Adam Grare
@agrare
Yeah I didn't think vmware created an ad-hoc network like that
samson7point1
@samson7point1
Yeah, as soon as they told me I figured that we would need the backing type after all.
I've never seen it do that before.
Adam Grare
@agrare
it wouldn't be configured on any host portgroup
samson7point1
@samson7point1
Exactly which is why it won't connect
Adam Grare
@agrare
just when you thought you'd seen it all
samson7point1
@samson7point1
I got conflicting stories about whether it could be manually connected because if they happened to try to attach it to a valid network it would work.
yep
Are we talking a minimum 2 weeks on this?
I'm going to have them test the vmware_guest ansible module to see if it's doing the same thing or handling the networks properly.
In the mean time if you need any other info from CloudForms, like another infomation dump, I can try to get that for you, but we'll probably lose access after this week.
Fabien Dupont
@fdupont-redhat
Hi. Does CloudForms collect the boot mode of the VM, i.e. BIOS or UEFI ?
Fabien Dupont
@fdupont-redhat
Other question. Today, to get the thumbprint of the ESXi host, we perform an authentication. Wouldn't it be easier to collect it during the inventory. Using pyVmomi, the attribute is host.summary.config.sslThumbprint. This information is useful for SmartState and Migration.
Adam Grare
@agrare
@fdupont-redhat do you know what the attribute is for bios vs uefi?
I see config.bootOptions.efiSecureBootEnabled but that's not exactly the same thing as bios vs efi
ah found it, its just config.firmware
Fabien Dupont
@fdupont-redhat
Yep. Just found the same.
Adam Grare
@agrare
I feel like we did this a while ago...
should be trivial to add since its in the schema already, I'll have a PR shortly
Fabien Dupont
@fdupont-redhat
Ok, so I found the firmware_type attribute, but it's empty on all VMs.
Thanks
Adam Grare
@agrare
for the sslThumbprint I think we checked with roliveri and he thought that property didn't exist when they wrote it originally