delta/libvirt.git/tests/bhyvexml2argvdata, branch master

bhyvexml2argvtest: use virCommandToStringFull to strip command path

2021-04-21T12:20:03+00:00

Currently the tests would fail if the bhyve commands are installed in
different path then /usr/bin. Strip the command path to not depend on
the host environment.

Signed-off-by: Pavel Hrdina 
Reviewed-by: Daniel P. Berrangé

bhyvexml2argvtest: Use internal wrapping of command line arguments

2021-04-12T13:55:10+00:00

virCommandToString has the possibility to return an already wrapped
string with better format than what we get from the test wrapper script.

The main advantage is that arguments for an option are always on the
same line which makes it more easy to see what changed in a diff and
prevents re-wrapping of the line if a wrapping point moves over the
threshold.

Signed-off-by: Peter Krempa 
Reviewed-by: Ján Tomko 
Reviewed-by: Pavel Hrdina

bhyve: add support

2021-03-20T03:53:45+00:00

Implement "" support for bhyve driver.
As there are not really lot of options, try to find
"BHYVE_UEFI.fd" firmware which is installed by the
sysutils/uefi-edk2-bhyve FreeBSD port.

If not found, just use the first found firmware
in the firmwares directory (which is configurable via
config file).

Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Michal Privoznik

bhyve: auto allocate nmdm console paths

2021-02-08T14:50:47+00:00

Currently, nmdm console device requires user to specify master and slave
path attributes (such as /dev/nmdm0A and /dev/nmdm0B respectively).
However, making user find a non-occupied device name might be not
convenient, especially for the remote connections.

Update the logic to make these attributes optional. In case if not
specified, use /dev/nmdm$UUID[AB], where $UUID is a domain's UUID.
With this schema it's unlikely nmdm device will clash with other domains
or even other non-bhyve nmdm devices.

Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Ján Tomko

bhyve: fix virtio-9p src/dst order

2020-10-12T11:24:21+00:00

For the virtio-9p bhyve command line argument, the proper order
is mount_tag=/path/to/host/dir, not the opposite.

Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Michal Privoznik

bhyve: implement virtio-9p support

2020-10-09T14:46:04+00:00

Recently virtio-9p support was added to bhyve.

On the host side it looks this way:

  bhyve .... -s 25:0,virtio-9p,sharename=/path/to/shared/dir

It could also have ",ro" suffix to make share read-only.

In the Linux guest, this share is mounted with:

  mount -t 9p sharename /mnt/sharename

In the guest user will see the same permissions and ownership
information for this directory as on the host. No uid/gid remapping is
supported, so those could resolve to wrong user or group names.

The same applies to the other side: chowning/chmodding in the guest will
set specified ownership and permissions on the host.

In libvirt domain XML it's modeled using the 'filesystem' element:

  
    
    
  

Optional 'readonly' sub-element enables read-only mode.

Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Michal Privoznik

bhyve: add VNC password support

2020-09-22T13:19:26+00:00

Support setting a password for the VNC framebuffer using the passwd
attribute on the  element, if the driver has the
BHYVE_CAP_VNC_PASSWORD capability.

Note that virsh domxml-from-native does not output the password in the
generated XML, as VIR_DOMAIN_DEF_FORMAT_SECURE is not set when
formatting the domain definition.

Signed-off-by: Fabian Freyer 
Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Daniel P. Berrangé

bhyve: add support for setting fbuf resolution

2020-09-22T13:19:26+00:00

The resolution of the VNC framebuffer can now be set via the resolution
definition introduced in 5.9.0.

Also, add "gop" to the list of model types  the 
sub-element is valid for.

Signed-off-by: Fabian Freyer 
Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Daniel P. Berrangé

bhyve: add missing test files

2020-09-22T11:59:37+00:00

Fixes: 4277e61e22b7532dc476c44a356081053da470f8
Signed-off-by: Roman Bogorodskiy

bhyve: soften requirements for slot 1

2020-09-21T16:03:45+00:00

Currently, slot 1 is only allowed to be used by the LPC device.
Relax this requirement and allow to use slot 1 if it was explicitly
specified by the user for any other device type. In this case the LPC
device will have the next available address.

If slot 1 was not used by the user, it'll be reserved for the LPC
device, even if it is not configured to make address assignment
consistent in case the LPC device becomes necessary (e.g. the user
adds a console or a video device which require LPC).

Signed-off-by: Roman Bogorodskiy 
Reviewed-by: Daniel P. Berrangé