On Wed, Dec 12, 2018 at 10:16 AM +0100, Marc Hartmayer <mhartmay@xxxxxxxxxxxxx> wrote: > On Tue, Dec 11, 2018 at 08:22 PM +0100, Cole Robinson <crobinso@xxxxxxxxxx> wrote: >> 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 have not only the installation use case in my mind. > >> >> 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 > > Yep, this is exactly the use case I’ve in mind. But instead of > “reverting” I would simply use virDomainCreateXML for the creation of a > transient domain. With this approach we get “the revert” after a > shutdown for free. > > The steps would be: > > 1. Get the persistent domain XML definition of a domain (code for that > could be shared between virt-xml/virt-install/…) > 2. Edit the XML (shared code as well) > 3. Create the transient domain by passing the edited XML to > virDomainCreateXML > > For the first time, I was surprised that this worked. Here is an simple > bash example for that: > > $ virsh create <(virsh dumpxml ${DOMAIN_NAME}) > >> 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 > > The point is virt-xml operates only on specific XML nodes, e.g. disk > node(s), (as far as I understand) and it _does not_ change the domain > lifecycle state. What we need is to consider the whole domain definition > and to change the domain lifecycle state. > >> and not create another whole command which adds a lot of >> maintenance overhead > > Yep, we must try to keep the maintenance overhead as low as possible! I > think this could be achieved by refactoring and adding more unit tests > for the basic functionalities. > >> >> Thanks, >> Cole >> > > If you’re still saying 'virt-xml' is the best place for that > functionality then I can surely add something like a '--start' option to > 'virt-xml'. > > Thanks for your feedback! > > -- > Kind regards / Beste Grüße > Marc Hartmayer > > IBM Deutschland Research & Development GmbH > Vorsitzende des Aufsichtsrats: Martina Koederitz > Geschäftsführung: Dirk Wittkopp > Sitz der Gesellschaft: Böblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294 Polite ping :) -- Kind regards / Beste Grüße Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list