[virt-tools-list] virt-xml/start: Temporarily use another boot configuration

[Cole Robinson]

On 01/09/2019 06:41 AM, Marc Hartmayer wrote:
> 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 :)

No objections, indeed if you want general purpose edit+start then 
extending virt-xml is the place to improve things.

Originally it was a design decision to have virt-xml only operate on 
single blocks of XML classes at a time. This is fixable but things get 
ambiguous. Consider currently editing cpu, you'll do

   virt-xml $VM --edit --cpu FOO

Okay. If we want to edit clock and cpu, what format do we use?

   virt-xml $VM --edit --cpu FOO --clock BAR   # or
   virt-xml $VM --edit --cpu FOO --edit --clock BAR

In that case maybe we could even make --edit optional, but we can't for 
device editing which often requires a value passed to --edit. The 
command line gets a little wonky having to have a matching --edit with 
every XML block. Also even trickier when we get into hotplug operations 
like --attach-device which are inherently serialized operations, if we 
fail half way through a list of hotplug operations the VM is in a weird 
state. But maybe we just disable the multi feature for hotplug operations

Those aren't necessarily blockers but just food for thought.

For the Create handling, it might be as simple as:

dom = <libvirt virDomain>
guest = virtinst.Guest(parsexml=dom.XMLDesc(...))
<make your guest edits>
installer = virtinst.Installer()
installer.start_install(guest, transient=True)

Thanks,
Cole