Bug 1108711

Hi Nir,

I do not think this is something host-deploy is doing.

Not sure even what "it" is...

Alon

Allon, how can help with this issue? do you think that multipath configuration is related?

Nir, where are we on that one?

I don't see any rellation to storage, don't know why it tagged "storage".

(In reply to Nir Soffer from comment #4)
> I don't see any rellation to storage, don't know why it tagged "storage".

this is a great response!

from comment#0:
"""
have rhel6 host installed with friendly_names "on" in multipath
"""

please help to determine what happens and why.

Can you specify the vdsm version reproducing this issue?

Ben, according to the info in the customer ticket, modifying multipath configuration requires rebuilding of initramfs.

So would you suggest that vdsm will rebuild initramfs each time it changes multipath configuration?

(In reply to Nir Soffer from comment #10)
> Ben, according to the info in the customer ticket, modifying multipath
> configuration requires rebuilding of initramfs.
> 
> So would you suggest that vdsm will rebuild initramfs each time it changes
> multipath configuration?

Yes.

There are some changes that don't require you to rebuild the initramfs, but it never hurts to do it, and it's a lot easier than trying to figure out if the specific change requires an initramfs rebuild.

Related to bug 1124450.

We cannot rebuild initramfs from vdsm startup. We must wait until multipath configuration is moved to vdsm-tool.

(In reply to Nir Soffer from comment #13)
> We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> configuration is moved to vdsm-tool.

hmmm.... not sure I understand, are you implying that deploy requires reboot?

(In reply to Alon Bar-Lev from comment #14)
> (In reply to Nir Soffer from comment #13)
> > We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> > configuration is moved to vdsm-tool.
> 
> hmmm.... not sure I understand, are you implying that deploy requires reboot?

No, but when we change multipath.conf, we must recreate initramfs (see comment 11), and it does not make sense that we do this behind the administrator back during vdsm startup.

bug 1076531 will hopefully be resolved soon by http://gerrit.ovirt.org/30909

(In reply to Nir Soffer from comment #15)
> (In reply to Alon Bar-Lev from comment #14)
> > (In reply to Nir Soffer from comment #13)
> > > We cannot rebuild initramfs from vdsm startup. We must wait until multipath
> > > configuration is moved to vdsm-tool.
> > 
> > hmmm.... not sure I understand, are you implying that deploy requires reboot?
> 
> No, but when we change multipath.conf, we must recreate initramfs (see
> comment 11), and it does not make sense that we do this behind the
> administrator back during vdsm startup.

It is insane to depend on pre-rootfs operations, initramfs should only be used to be able to execute pid 1 from rootfs.

(In reply to Alon Bar-Lev from comment #16)
Your rootfs may be on a multipath device which you boot from. To successfully boot from the device, you need multipath.conf.

It may be insane but thats what users do (see bug 1124450).

This is actually depends on bug 1124450, since the current multipath.conf we create will not let you boot on rhel 6.

This bug depends on BZ 1076531, which won't be resolved before 3.6.0.

(In reply to Allon Mureinik from comment #19)
> This bug depends on BZ 1076531, which won't be resolved before 3.6.0.
This is MODIFIED, meaning we can start working on THIS bug upstream.

Oved, this seems like more of an infra/integration issue since we have to rebuild initramfs after modifying multipath.conf and thus not related directly to storage
Can someone from infra take it or you think it's more of an integration issue?

same here.. rebuilding initramfs, im not aware of what it means regarding changing multipath configurations.. sorry. (you can tell me more after you figure that out and I might be able to add it myself) Currently Yeela managed the movement of multipath configuration part to the centralized place under vdsm-tool. but setting multipath configuration is storage related and I prefer that you'll take over it instead of us making mistakes without knowing the consequences. If something need to be modified in lib/vdsm/tool/configurators/multipath.py I think you should do it.. don't you? please explore what it means to rebuild the initramfs, how and why it should be done, and we'll consider how we do it.. I never bumped in such issue (danken, maybe you did?)

This bug only effects people that manually added multipath to their initramfs and not for all people (unless multipath is now in initramfs by default).
I don't know if there is a way to detect that multipath was added to initramfs and in any case, rebuilding it seems a bit problematic to me.

It's another issues that crops up because we allow people to do what they want with their system while in the same time configuring the system ourselves.

Supporting *any* initramfs is going to be really problematic so I don't suggest we start going down that road. If there is a way to detect that an initramfs should be rebuilt we could have vdsm-tool warn about it.

In any case, the real fix is that storage stop depending on `user_friendly_names no`.

People need to tweak their initramfs's multipath.conf in order to boot from a multipath-served disk.

However, these people change their multipath.conf manually. I don't see a benefit in automatically copying ovirt's multipath.conf into initramfs - it would override their changes. Whomever edits his multipath.conf and intend to use his host for ovirt, would need to comply with ovirt's requirement.