On 01/09/2019 06:41 AM, Marc Hartmayer wrote:
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 :)
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
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
