On 12/11/2018 08:18 AM, Marc Hartmayer wrote:
Hi all, I’m planning to implement a functionality that allows the user to temporarily use another boot configuration than defined in the persistent XML. For example it should be possible to boot from another kernel/initrd/cmdline (via direct boot) and it should also be possible to select to boot from a network/disk/hostdev device. So far so good but I’m unsure where this functionality fits in… First I thought I could extend virt-xml, but since virt-xml is only used for editing the domain definition and not for changing the state of a domain (stopped->running) it might not be the best fit. Therefore I thought a better option would be to add another tool aka 'virt-start' and refactor shared code between 'virt-(install|xml)'. * What is your opinion about that? * How should the CLI look like? The main motivation behind this is that the s390 architecture knows only one boot device and therefore the boot order settings doesn't work the way it would work on x86, for example. If the first boot device fails to boot there is no trying to boot from the next boot device. In addition, the architecture/BIOS has no support for interactively changing the boot device during the boot/IPL process.
I've thought for a while about adding a 'virt-install --reinstall $VMNAME $INSTALLOPTIONS' which I think would cover this usecase. It really only became feasible with some of the code rework in the 2.0.0 release, nowadays it should be fairly straightforward.
I think there's also a usecase for a generic 'start the VM and make these one time changes to it, then revert' feature but that might have slightly different semantics than reinstall, I'd need to think about it more. Either way my preference would be to fold this into virt-install or virt-xml and not create another whole command which adds a lot of maintenance overhead
Thanks, Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
