[virt-tools-list] virt-xml/start: Temporarily use another boot configuration
Marc Hartmayer
mhartmay at linux.ibm.com
Wed Jan 9 11:41:59 UTC 2019
On Wed, Dec 12, 2018 at 10:16 AM +0100, Marc Hartmayer <mhartmay at linux.ibm.com> wrote:
> On Tue, Dec 11, 2018 at 08:22 PM +0100, Cole Robinson <crobinso at redhat.com> 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
More information about the virt-tools-list
mailing list