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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
