Are these Virtualization features on the roadmap?

[beagle]

I believe one of the features attracting users to SCALE is the addition of a more mature virtualization solution available on Linux to an already mature ZFS based storage solution. However when we compare the virtualization features, UI and UX currently offered on SCALE to more mature virtualization solutions like XenOrchestra / XCP-ng and Proxmox there are some opportunities for improvement.

To avoid a wall of text I'll split my suggestions in multiple messages and I would appreciate to hear if these features are on the roadmap or it's worth opening a feature request for them.

(1) UI / UX

Maybe I'm not as familiar to SCALE's interface as I am with the other solutions but I find myself taking several steps to access information that are more easily accessible on XenOrchestra for example (see screenshots below).

The tabbed view gives easy access to details of all the VM features: disks, network, snapshots, boot order, etc



(2) Network

I couldn't find an option to create an internal isolated network. And, I also couldn't find the IPs associated to a running VM.

In XenOrchestra, the Network tab shows all the NICs and their details. You can also easily attach or detach a NIC (external or internal).

 

[Patrick M. Hausen]

I couldn't find an option to create an internal isolated network.

You would have to create a bridge interface for that.

 

[beagle]

(3) Storage

When you add a new disk to the VM it seems you can't create a new ZVOL you can only attach an existing one.

I couldn't also find an option to increase the disk size directly from the Virtualization view.

In XenOrchestra (XO), adding a new disk, attaching an existing disk and increasing disks sizes are options directly available on the Disks tab.

Another interesting feature is import/export the disks in VHD format that allows exchanging VM disks with other hypervisors.

(4) Snapshots

There is not an option integrated in the VM view to take VM snapshots. I'm no expert by I think when you take a VM snapshot with libvirt it snapshots not only the disk but also the VM metadata. It also offers the feature to freeze and unfreeze the VM during the snapshot to avoid data corruption.

The only option I could find to take a snapshot of a VM on SCALE is going to Storage and directly taking a snapshot of the ZVOL used by the VM. That option also doesn't provide an integrated view of all the snapshots related to that VM like a tabbed view does.

Another missing feature is being able to create a new VM based on an existing VM snapshot. In XO, there is a button next to each snapshot to create a new VM based on that snapshot.

(5) Templates

There is no option to create a VM as a template and use that template to create new VMs. It would also be useful to be able to use cloud-init to set parameters (e.g. NICs, disk size, ssh keys, users, etc) when using the templates to create new VMs.

Many distributions offer "cloud" images that could be imported as templates. A hub with official images would be a welcome addition.

(6) Import/Export VMs in OVA format

Some developers use the OVA format to distribute appliances and demos of their applications. It's also an versatile format to transfer VMs between systems.

(7) VM migration

That one is probably on the roadmap for a future version. Being able to migrate VMs between nodes is an important feature when we consider the concept of multiple nodes embedded in SCALE.

XO can automatically migrate VMs between nodes when the system is updated or shutdown. Or can be manually triggered by the user.

I'm sure there are many more features that can be implemented that would used VM migration like load balancing between nodes, etc

 

[beagle]

You would have to create a bridge interface for that.

Isn't a bridge always attached to a physical NIC?

When I say an internal network I mean a network that is internal to the hypervisor. For example, a webserver running on a VM and a DB running on a separate VM. The webserver has 2 NIC's, one attached to a physical NIC that is externally accessible and other internal to connected to an internal network. The DB VM has only one NIC connected to the internal network and not accessible externally.

 

[Patrick M. Hausen]

Isn't a bridge always attached to a physical NIC?

No. you can have an arbitrary number of bridges to connect an arbitrary number of VMs without any connection to the outside world.
I don't know if the UI of either CORE or SCALE currently permits that but be assured that I run this configuration in my data centre and it works perfectly.

A bridge is a switch and a switch is a bridge. Even in VMware you have the "vSwitch" and can connect it to a physical or not as desired.

 

[beagle]

I don't know if the UI of either CORE or SCALE currently permits that

That's a feature request then

 

[jgreco]

A bridge is a switch and a switch is a bridge. Even in VMware you have the "vSwitch" and can connect it to a physical or not as desired.

Well, technically a bridge is a two-sided affair, designed simply to control the propagation of useless traffic while making it look and feel mostly like a single broadcast domain between two multiple access networks (10base-5 or 10base-2). Later, a two-sided bridge became a "simple bridge" and then you got into multiport bridges, which are very similar to switches. However, in practice, switches have features that bridges do not, specifically including dedicated silicon designed for the purpose of rapid packet processing, while bridges were just specialized mini-hosts with two 10Mbps interfaces.

It is not clear to me why the FreeBSD guys called their virtual software switch a "bridge".

And of course this is all just silly pedantry.

 

[Patrick M. Hausen]

Radia Perlman, "Interconnections":

A device making forwarding decisions based on layer 2 information is a bridge.
A device making forwarding decisions based on layer 3 information is a router.
A "switch" has no precise definition.

I agree about the "simple" vs. "multiport", but essentially all bridges are multiport, i.e. switches today.

 

[inman.turbo]

5) Templates

There is no option to create a VM as a template and use that template to create new VMs. It would also be useful to be able to use cloud-init to set parameters (e.g. NICs, disk size, ssh keys, users, etc) when using the templates to create new VMs.

Many distributions offer "cloud" images that could be imported as templates. A hub with official images would be a welcome addition.

I've mentioned this myself, this would be an excellent feature (current versions of Cockpit allow "unattended install" of cloud images, via automatic download). As would better networking options. Here is an example network that might be used in libvirt to allow vms access to storage shares without going out through a NIC:

Code:

<network>
  <name>isolated</name>
  <bridge name="virbr1" stp="off" delay="0"/>
  <mtu size='9000'/>
  <mac address="xx:xx:xx:xx:xx:xx"/>
  <domain name="network"/>
  <ip address="192.168.254.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.254.100" end="192.168.254.200"/>
      <host mac="xx:xx:xx:xx:xx:xx" ip="192.168.254.254"/>
    </dhcp>
  </ip>
</network>

 

[jgreco]

Radia Perlman, "Interconnections":

A device making forwarding decisions based on layer 2 information is a bridge.
A device making forwarding decisions based on layer 3 information is a router.
A "switch" has no precise definition.

That's nice, but is really only staking out one position. Switches had a reasonably precise definition until features started getting added, then the marketing people wanted to get involved because "layer 3 switch" sounded so much better to a generation who had come to despise "router" because the '90's had been mostly software routing (be careful here, my office printer stand is an Ascend GRF-400 so I am prepared to discuss this in excruciating detail, hahah). By an equally valid point of view, a bridge doesn't have stuff like spanning tree or packet filtering, it is merely a way to make a large broadcast domain manageable from a traffic perspective. Which is why I find the FreeBSD naming a little ... random.

Also, while there is a certain simplicity in the Perlman definition, it is unworkable in practice. Many layer 3 switches, for example, with two ethernets, one mtu 9000, one mtu 1500, will not properly handle that situation as a router (fragmentation/MTU issues will result). A packet trying to egress an interface with an insufficiently large MTU is expected to be fragmented by the router's outgoing interface so that it "just works." Switches generally will not do that. You can work around that by still calling it a router, but even the switch vendors aren't quite that stupid.

That does not mean that I am *happy* that there's lots of gray in there.

I agree about the "simple" vs. "multiport", but essentially all bridges are multiport, i.e. switches today.

Not to those of us who remember the fine old days of setting up networks with DEBET's, DELNI's, and DEMPR's. I might still have some around. I definitely have AUI and 10base-2 gear, and maybe some thicknet somewhere... I also have some PortMaster 2's and a pile of modems if anyone wants to get nostalgic and build a 90's ISP. ;-)

 

[Patrick M. Hausen]

Not going into an endless debate, but the FreeBSD bridge(4) of course has spanning tree. A protocol Mrs. Perlman invented, btw.

 

[jgreco]

Not going into an endless debate, but the FreeBSD bridge(4) of course has spanning tree. A protocol Mrs. Perlman invented, btw.

Right, that's my point. Bridging is a simple function and doesn't have complicated protocols as part of it. Even VMware calls their software switch a vSwitch, not a vBridge.

Also, I'm aware of who Radia Perlman is. It is not necessarily a point in her favor, spamming tree being as atrocious as it is.

 

[wootin]

Has anyone actually tried creating a bridge for an internal network?
When I tried in the GUI the GUI demanded a NIC for the bridge.
I suppose that you could manually do it in the CLI but that not what this post is about.
I would love to see a similar implementation to Proxmox.
I am sure SCALE will get there. Its still early days

 

[wootin]

Has anyone actually tried creating a bridge for an internal network?
When I tried in the GUI the GUI demanded a NIC for the bridge.
I suppose that you could manually do it in the CLI but that not what this post is about.
I would love to see a similar implementation to Proxmox.
I am sure SCALE will get there. Its still early days

update - creating the bridge worked for me in latest nightly

 

[beagle]

Is there a way to duplicate a VM via GUI? Cloning doesn't create an "independent" VM it uses a cloned zvol as disk that is related to the original zvol. Therefore if I create multiple clones I can't delete the original VM.

 

[Patrick M. Hausen]

Is there a way to duplicate a VM via GUI?

No. But you can easily copy the zvol via e.g.

Code:

zfs snapshot ssd/vms/windows-disk0@now
zfs send ssd/vms/windows-disk0@now | zfs receive ssd/vms/windows-copy-disk0
zfs destroy ssd/vms/windows-disk0@now
zfs destroy ssd/vms/windows-copy-disk0@now

and create a VM using ssd/vms/windows-copy-disk0 afterwards.

 

[beagle]

I'm planning to open a few feature requests on Jira with some of the suggestions on the OP. It would be good to hear if any of these suggestions are already on the roadmap? Maybe @morganL or @Kris Moore could chime in?

 

[ornias]

@beagle As someone that actually has been discussing a lot of features with IX, I can tell you they REALLY prefer if you just create a few suggestions on the Jira.
Even if you get Kris, Morgan or someone else to say "Yeah sounds awesome", that would just mean THEY have the make the same Jira issue...
Most efficient is creating a few Jira issues and tagging the people you want to look at them in Jira or at the Slack chatbox.

It would be even beter if you could add some implementation guides or some sketches if you already have somewhat if an idea for an UI in mind.

TLDR:
Instead of:
You -> Employee -> Jira -> Feature

Do:
You -> Jira -> Employee -> Feature

 

[beagle]

Thank you @ornias. I was always planning to open the tickets on Jira. Just wanted to avoid the additional work of creating features that were already planned in the roadmap or completely out of sync with any futures plans.

 

[Kris Moore]

Thank you @ornias. I was always planning to open the tickets on Jira. Just wanted to avoid the additional work of creating features that were already planned in the roadmap or completely out of sync with any futures plans.

We don't mind duplicate tickets, rather close a few that are redundant than have an idea die on the forums because we forgot to get a ticket made.

But yes, please put in suggestion ticket and we'll make sure it stays on our radar and evaluated for inclusion in a future update to TrueNAS.