Create Virtual Machine functionality
by Marek Libra
Hi,
as a next step for the cockpit-machines, I plan to implement the "Create
VM" functionality.
Before doing that, I would like to collect ideas, agreement on scope and
preferably on design.
The long term vision is support for (almost) all features as virt-manager
has.
Definitely, path to this goal has to be splited into smaller steps,
starting with something generic enough but providing just the minimum and
useful functionality.
The component will be reusable for both "New VM" and "Edit VM" flows.
Will be implemented as a wizard, user can navigate back and forth, maybe
even "jump" into a step of his choice.
Wizard can be canceled in every step.
All write operations are postponed until final "submit".
Optional "external provider" will be able to extend the wizard dialogs and
will handle the "Submit".
Initial implementation:
Wizard dialog 1: Basic props
- VM name
- vcpus
- memory
- qemu connection (whether session or system)
Wizard dialog 2: Disks
- single disk's params
Wizard dialog 3: Boot order
- cdrom iso file
- from an associated disk
Wizard dialog 4: Consoles
- select none or any combination from
- SPICE
- VNC
- address and port can be specified, defaults provided
Wizard dialog 5: Summary
- All entered details are listed (tree-list component?)
- User can navigate back, cancel or submit
High-priority follow-ups:
- User can select multiple existing disks and/or create multiple new ones
- "Networks" wizard dialog plus PXE boot
- "submit and run" functionality
- "Edit VM"
- cdrom iso from network source (URL)
Later on, new wizard dialogs can be added or existing ones extended.
So far I considered but rejected these other concepts:
- single complex dialog (no wizard, sort of "functionality grouping"
would be still required)
- "Edit" functionality mixed with the recent presentation components
(nightmare for more complex configuration)
I'm looking for feedback - e.g. UX, extensibility, scope or whatever to be
taken for consideration.
Thanks,
Marek
--
Marek Libra
senior software engineer
Red Hat Czech
<https://www.redhat.com>
6 years, 10 months
Remotable Libvirt
by Peter
Hi Everyone,
We are working towards building on the virtualization management
functionality in cockpit (http://cockpit-project.org/) and wanted to get
some feedback on the best way to integrate with libvirt.
As a quick overview, cockpit aims to talk to existing remotable system
APIs. Usually these API’s take the form of dbus, REST or executable
commands. The majority of cockpit is implemented in javascript. There is
no cockpit backend that knows how to change a hostname for example. The
cockpit backend knows how to handle a dbus payload. The javascript
running in the users browser knows how to use the systemd dbus API at
org.freedesktop.hostname1 to manage the system hostname.
Right now some of the basics have been implemented by spawning commands
on the system. This isn't ideal because it involves parsing / screen
scraping output and doesn't support receiving events so we have to poll
(ei run the command again) to keep the UI up to date.
As far as I know libvirt doesn't currently have a remoteable API. It
does have a daemon that communicates with clients via a XDR RPC.
(https://libvirt.org/internals/rpc.html) However from what I'm hearing
the RPC is considered an internal implementation and shouldn't be used
by external applications. Is that still the case? Is there any chance of
getting talking the daemon directly using the XDR standard for a subset
of methods blessed as part of the externally supported API?
An alternative is to implement a standards based remotable API, using
something like dbus or REST, that can be used by external applications.
I imagine that this would be at a bit of a higher level than the current
RPC and contain at least some of the logic around the actions it
performs rather than being a direct passthrough to the daemon.
Of course that is a pretty big undertaking and would, in my opinion,
only be worth it if there is broader interest in the community and use
cases beyond what cockpit would like to.
6 years, 10 months
Fwd: Re: [libvirt] Remotable Libvirt
by Peter
-------- Forwarded Message --------
Subject: Re: [libvirt] Remotable Libvirt
Date: Tue, 6 Jun 2017 08:17:43 -0700
From: Peter <petervo(a)redhat.com>
To: libvir-list(a)redhat.com
On 06/06/2017 08:11 AM, Peter Krempa wrote:
> On Tue, Jun 06, 2017 at 07:45:10 -0700, Peter wrote:
>> On 05/26/2017 02:11 AM, Martin Kletzander wrote:
>>> On Thu, May 25, 2017 at 10:16:26AM -0700, Peter Volpe wrote:
>
> [...]
>
>>> If we standardize even the smallest part of the RPC, then it might screw
>>> us immediately. We are keeping it private just so we can enhance the
>>> APIs we already have. We don't know when we will need to change some
>>> part of it.
>>>
>>
>> How does the current ssh implementation work?
>> (https://libvirt.org/remote.html) If clients are able to talk to a remote
>> libvirtd via ssh then there must be some sort of compatibility guarantee.
>> Otherwise unless the versions are exactly the same clients wouldn't be able
>> to talk to remote daemons.
>
> They use the internal RPC protocol transported over SSH. The client
> library initializes the ssh connection to the server, and then starts to
> talk the RPC tunelled over the SSH session.
>
> The compatibility is guaranteed only if you use the client library. As
> said, the RPC protocol is considered an internal detail and the client
> library shields you from a possible incompatibility if we'd ever make
> incompatible change.
>
How does the client or server handle differing versions between them,
when the protocol changes? Or is it that client.x.x can only talk to
servers with the same exact version?
> --
> libvir-list mailing list
> libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
6 years, 10 months
