While integrating domUloader with xen 3.1.0/unstable, I questioned the
usefulness of bootable field in class vbd. It is only used in
XenDomainInfo._configureBootloader - and there I have a small local
patch that removes restriction of only 'bootable' disks being considered
for bootloader invocation. In cases where the kernel/ramdisk reside on
> 1st disk, the bootable field is not set (see line 994 and 1003 in
XendConfig.py where only first disk is set bootable) and bootloader is
passed incorrect disk.
The bootable field can be set via Xen API but there is no way to specify
it in legacy config files. I have a working patch to add specifying
bootable via config file, e.g.
disk = [ 'phy:hda1,hda1,w, bootable' ]
but not sure if this is proper approach. Another idea would be to pass
a list of disks to bootloader and, in conjunction with bootloader args,
let it find the disk containing kernel/ramdisk. And last idea would be
to leave things as is and I maintain the domUloader integration patch
:-). It has become smaller in the move to 3.1.0.
Not sure about the notion of bootable disks for pv guests. The kernel
can live on any of domain's vbds, or on dom0 fs. In the latter case,
what does it mean for one of the vbds to be bootable?
Regards,
Jim
_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
usefulness of bootable field in class vbd. It is only used in
XenDomainInfo._configureBootloader - and there I have a small local
patch that removes restriction of only 'bootable' disks being considered
for bootloader invocation. In cases where the kernel/ramdisk reside on
> 1st disk, the bootable field is not set (see line 994 and 1003 in
XendConfig.py where only first disk is set bootable) and bootloader is
passed incorrect disk.
The bootable field can be set via Xen API but there is no way to specify
it in legacy config files. I have a working patch to add specifying
bootable via config file, e.g.
disk = [ 'phy:hda1,hda1,w, bootable' ]
but not sure if this is proper approach. Another idea would be to pass
a list of disks to bootloader and, in conjunction with bootloader args,
let it find the disk containing kernel/ramdisk. And last idea would be
to leave things as is and I maintain the domUloader integration patch
:-). It has become smaller in the move to 3.1.0.
Not sure about the notion of bootable disks for pv guests. The kernel
can live on any of domain's vbds, or on dom0 fs. In the latter case,
what does it mean for one of the vbds to be bootable?
Regards,
Jim
_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api