[ovirt-users] Re: Direct Linux kernel/initrd boot
On Tue, Jul 27, 2021 at 12:10 PM Yedidyah Bar David <didi(a)redhat.com> wrote:
On Tue, Jul 27, 2021 at 11:56 AM Shani Leviim <sleviim(a)redhat.com> wrote:
>
> Hi Chris,
> Indeed, the ISO domains are deprecated, and you can use a data domain for uploading
iso files (as you've mentioned).
> To do that, you need to use image-io for uploading images
>
> Here's image-io documentation:
http://ovirt.github.io/ovirt-imageio/overview.html.
>
> Then you can use the UI (admin portal) or REST API for uploading the iso image to
the relevant storage domain.
Shani, I think Chris asked specifically about booting from an image. See e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=1122970#c34
Is that intended to be handled? It seems like we gave up on removing
the ISO domain concept, perhaps also because of this missing feature -
see last few comments of:
https://bugzilla.redhat.com/show_bug.cgi?id=1543512
Adding Michal. Michal - IMO we should make up our minds and provide a
clear view - either undeprecate the ISO domain - remove deprecation
notices from everywhere - or provide concrete plans to fill the
missing gaps.
Forcing NFS storage domain in a system with high end FC/iSCSI storage
does not make sense, and introduces reliability issues due to NFS unpredictable
timeouts. We don't want to go back to having NFS on every system.
Uploading to data domain should work for all use cases. If something
does not work (booting from kernel image on data domain) it's a bug,
probably something that was missed when we add the feature to keep iso
disks on block storage.
The issue with data domain is sharing the same domain with multiple DCs.
This is not supported now since only one SPM can manage the storage
domain (e.g create a new disk). But we have the infrastructure to support
this.
Of course we can support upload to iso domain, this depends on engine setting
up the transfer properly, and probably requires new APIs in vdsm to
create the file
in the iso domain.
Nir