[RFC] Guest Network Boot support [Part1] - Create template and guest with support to Direct Boot
Alan Evangelista (https://github.com/alanoe) and I are willing to implement the support to Network Boot to Kimchi guests. This is the first approach [Part1] we are going to develop: The direct boot When finished, we are going to send [Part2] that will cover DHCP/TFTP, etc. ------- This feature aims to develop Kimchi's support to create Guest that will boot over Network using Libvirt Direct Boot Libvirt details: https://libvirt.org/formatdomain.html#elementsOSKernel Kimchi related bug: https://github.com/kimchi-project/kimchi/issues/372 We see three major changes in Kimchi code: 1- Change Template creation and update (BACKEND) 2- Change Template creation and update (FRONTEND) 3- Change Guest creation (BACKEND) Details: 1- Change Template creation and update (BACKEND): Backend is going to wait for these new parameters (json) in Template creation or update: "netboot": { "kernel": "<KERNEL URL>", "initrd": "<INITRD URL>", "kernelargs": "<COMMAND LINE FOR KERNEL>", "repository": "<PACKAGE REPOSITORY>" (optional) } Steps: src/kimchi/API.json -> change "templates_create" and "template_update" to receive above parameters; src/kimchi/model/templates.py -> change "TemplatesModel.create()" to check if "netboot" comes to save data properly -> change "TemplateModel.update()" to check if "netboot" comes and update data properly; doc/API.md -> change to reflect new parameters; src/kimchi/i18n.py -> add new errors if needed; Other: - Change templates auto tests if necessary; - Change "VMTemplate" class in "src/kimchi/vmtemplate.py" in order to probe DISTRO and VERSION; 2- Change Template creation and update (FRONTEND): Front-end is going to have following changes: - Add new entry in 'Add Template' window: "Network Direct Installation"; - Create new window to allow user to provide new four parameters; - Change Template update window. Add new tab to change or add network installation parameters; 3- Change Guest creation (BACKEND) Here it is necessary to change the XML creation, so we need to: src/kimchi/vmtemplate.py -> change "VMTemplate.to_vm_xml()" to check existence of parameter "netboot", then change <os> element properly. Other: - Change guests auto tests if necessary; - Change xml (VMTemplate) auto test if necessary; Rodrigo Trujillo
On 04/15/2015 12:20 AM, Rodrigo Trujillo wrote:
Alan Evangelista (https://github.com/alanoe) and I are willing to implement the support to Network Boot to Kimchi guests.
This is the first approach [Part1] we are going to develop: The direct boot It is an interesting feature while we may need to separate it from the net boot for me, because if we use netboot, we need to configure the boot order in <os> section. According to the doc of libvirt, the direct boot is restrained to boot order for me, and their xml manipulation flow may need to differentiate. When finished, we are going to send [Part2] that will cover DHCP/TFTP, etc.
-------
This feature aims to develop Kimchi's support to create Guest that will boot over Network using Libvirt Direct Boot Libvirt details: https://libvirt.org/formatdomain.html#elementsOSKernel Kimchi related bug: https://github.com/kimchi-project/kimchi/issues/372 We see three major changes in Kimchi code:
1- Change Template creation and update (BACKEND) 2- Change Template creation and update (FRONTEND) 3- Change Guest creation (BACKEND)
Details:
1- Change Template creation and update (BACKEND): Backend is going to wait for these new parameters (json) in Template creation or update:
"netboot": { "kernel": "<KERNEL URL>", "initrd": "<INITRD URL>", "kernelargs": "<COMMAND LINE FOR KERNEL>", "repository": "<PACKAGE REPOSITORY>" (optional) }
Steps: src/kimchi/API.json -> change "templates_create" and "template_update" to receive above parameters; src/kimchi/model/templates.py -> change "TemplatesModel.create()" to check if "netboot" comes to save data properly -> change "TemplateModel.update()" to check if "netboot" comes and update data properly; doc/API.md -> change to reflect new parameters; src/kimchi/i18n.py -> add new errors if needed;
Other: - Change templates auto tests if necessary; - Change "VMTemplate" class in "src/kimchi/vmtemplate.py" in order to probe DISTRO and VERSION;
2- Change Template creation and update (FRONTEND): Front-end is going to have following changes: - Add new entry in 'Add Template' window: "Network Direct Installation"; - Create new window to allow user to provide new four parameters; - Change Template update window. Add new tab to change or add network installation parameters;
3- Change Guest creation (BACKEND) Here it is necessary to change the XML creation, so we need to: src/kimchi/vmtemplate.py -> change "VMTemplate.to_vm_xml()" to check existence of parameter "netboot", then change <os> element properly.
Other: - Change guests auto tests if necessary; - Change xml (VMTemplate) auto test if necessary;
Rodrigo Trujillo
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 14/04/2015 13:20, Rodrigo Trujillo wrote:
Alan Evangelista (https://github.com/alanoe) and I are willing to implement the support to Network Boot to Kimchi guests.
This is the first approach [Part1] we are going to develop: The direct boot When finished, we are going to send [Part2] that will cover DHCP/TFTP, etc.
From what I understand, direct boot is not necessarily related to network boot. As you can specify any location to kernel/initrd, ie, any shared storage can fill this requirement. So I suggest to separate it from the network boot itself.
-------
This feature aims to develop Kimchi's support to create Guest that will boot over Network using Libvirt Direct Boot Libvirt details: https://libvirt.org/formatdomain.html#elementsOSKernel
As Royce pointed in the other email, we will probably have problems with the boot order while setting the <os> with these configuration. And while doing network boot we just need to properly configure the network interface and change the boot order.
Kimchi related bug: https://github.com/kimchi-project/kimchi/issues/372
This issue is not related to Direct boot. It is for Network boot (DHCP/TFTP). So in summary we have 2 different features: 1. Direct boot Collect info from user and properly set the XML like in https://libvirt.org/formatdomain.html#elementsOSKernel Problems to solve: - how do we update the boot order in this case? As I want to use it just for installation and after that the guest should boot from hd. 2. Network boot For reference: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virt... - We need to change the boot order, setting "network" as first option - Allow user to update the network interface configuration to reach the server
We see three major changes in Kimchi code:
1- Change Template creation and update (BACKEND) 2- Change Template creation and update (FRONTEND) 3- Change Guest creation (BACKEND)
Details:
1- Change Template creation and update (BACKEND): Backend is going to wait for these new parameters (json) in Template creation or update:
"netboot": { "kernel": "<KERNEL URL>", "initrd": "<INITRD URL>", "kernelargs": "<COMMAND LINE FOR KERNEL>", "repository": "<PACKAGE REPOSITORY>" (optional) }
Steps: src/kimchi/API.json -> change "templates_create" and "template_update" to receive above parameters; src/kimchi/model/templates.py -> change "TemplatesModel.create()" to check if "netboot" comes to save data properly -> change "TemplateModel.update()" to check if "netboot" comes and update data properly; doc/API.md -> change to reflect new parameters; src/kimchi/i18n.py -> add new errors if needed;
Other: - Change templates auto tests if necessary; - Change "VMTemplate" class in "src/kimchi/vmtemplate.py" in order to probe DISTRO and VERSION;
2- Change Template creation and update (FRONTEND): Front-end is going to have following changes: - Add new entry in 'Add Template' window: "Network Direct Installation"; - Create new window to allow user to provide new four parameters; - Change Template update window. Add new tab to change or add network installation parameters;
3- Change Guest creation (BACKEND) Here it is necessary to change the XML creation, so we need to: src/kimchi/vmtemplate.py -> change "VMTemplate.to_vm_xml()" to check existence of parameter "netboot", then change <os> element properly.
Other: - Change guests auto tests if necessary; - Change xml (VMTemplate) auto test if necessary;
Rodrigo Trujillo
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 20/04/2015 12:55, Aline Manera wrote:
On 14/04/2015 13:20, Rodrigo Trujillo wrote:
Alan Evangelista (https://github.com/alanoe) and I are willing to implement the support to Network Boot to Kimchi guests.
This is the first approach [Part1] we are going to develop: The direct boot When finished, we are going to send [Part2] that will cover DHCP/TFTP, etc.
From what I understand, direct boot is not necessarily related to network boot. As you can specify any location to kernel/initrd, ie, any shared storage can fill this requirement.
So I suggest to separate it from the network boot itself.
-------
This feature aims to develop Kimchi's support to create Guest that will boot over Network using Libvirt Direct Boot Libvirt details: https://libvirt.org/formatdomain.html#elementsOSKernel
As Royce pointed in the other email, we will probably have problems with the boot order while setting the <os> with these configuration.
And while doing network boot we just need to properly configure the network interface and change the boot order.
Kimchi related bug: https://github.com/kimchi-project/kimchi/issues/372
This issue is not related to Direct boot. It is for Network boot (DHCP/TFTP).
So in summary we have 2 different features:
1. Direct boot Collect info from user and properly set the XML like in https://libvirt.org/formatdomain.html#elementsOSKernel
Problems to solve: - how do we update the boot order in this case? As I want to use it just for installation and after that the guest should boot from hd.
2. Network boot For reference: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virt...
- We need to change the boot order, setting "network" as first option - Allow user to update the network interface configuration to reach the server
We see three major changes in Kimchi code:
1- Change Template creation and update (BACKEND) 2- Change Template creation and update (FRONTEND) 3- Change Guest creation (BACKEND)
Details:
1- Change Template creation and update (BACKEND): Backend is going to wait for these new parameters (json) in Template creation or update:
"netboot": { "kernel": "<KERNEL URL>", "initrd": "<INITRD URL>", "kernelargs": "<COMMAND LINE FOR KERNEL>", "repository": "<PACKAGE REPOSITORY>" (optional) }
Steps: src/kimchi/API.json -> change "templates_create" and "template_update" to receive above parameters; src/kimchi/model/templates.py -> change "TemplatesModel.create()" to check if "netboot" comes to save data properly -> change "TemplateModel.update()" to check if "netboot" comes and update data properly; doc/API.md -> change to reflect new parameters; src/kimchi/i18n.py -> add new errors if needed;
Other: - Change templates auto tests if necessary; - Change "VMTemplate" class in "src/kimchi/vmtemplate.py" in order to probe DISTRO and VERSION;
2- Change Template creation and update (FRONTEND): Front-end is going to have following changes: - Add new entry in 'Add Template' window: "Network Direct Installation"; - Create new window to allow user to provide new four parameters; - Change Template update window. Add new tab to change or add network installation parameters;
3- Change Guest creation (BACKEND) Here it is necessary to change the XML creation, so we need to: src/kimchi/vmtemplate.py -> change "VMTemplate.to_vm_xml()" to check existence of parameter "netboot", then change <os> element properly.
Other: - Change guests auto tests if necessary; - Change xml (VMTemplate) auto test if necessary;
Rodrigo Trujillo
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
Rodrigo Trujillo -
Royce Lv