While selection of user access per application certainly might represent a possibility for future improvement, I think the essence of the proposed feature is not directly dependent on such functionality.

I think the consents page would be more sensible to display after login, compared to the profile, but the page I had in mind would have some differences. One would be that a portal should show all the applications to which a user has rights, not just those to which consent has been granted. It should express the possibilities for exploring the site, from the standpoint of the applications that the administrator has provisioned.

By "configurable", I mean simply that the site administrator may provision a list of local applications that would be presented by name and hyperlink. Naturally, many further configuration settings are possible in principle, but the overarching observation is that every site will have different applications.

A presentation that is most visually pleasing would require logos in addition to names for applications, but such a feature entails greater complexity. The administrator must manually upload images, or an index of applications must be shipped with the application, or operated online. As a final case, it is possible in principle that applications support an interface for providing user-facing identification data dynamically, for example through various metadata tags served by its own presentation.

The use case is simple. A few applications are provisioned locally on a server for use by members of a small group.

After login directly to the application, the user is presented with a form representation of the user profile.

In most cases, the user will not need to edit the profile after login.

While in the common use case, login will be followed by redirection to the invoking application, some administrators may like to configure the site to present a list of available applications.

Requested is a configurable portal that would display a listing of site applications to be presented after login.

There may be no particular collision, but I am beginning to wonder whether your concerns would be easier to address in a different issue. I think the title you used earlier ("“Export to a HTML/Web-friendly SVG-type”) is a good one for the kinds of problems you have identified.

It seems to me there is a large difference in the reasons for the concerns. On one side is the question of how to create a static vector image that displays properly outside of Inkscape. On the other side is the question of how to use Inkscape to create SVG documents that have features desired in an interactive environment.

I think at the current point of development, of no strong support for either case, it might confuse the discussion to mix them. It would be helpful to avoid a situation of two groups of individuals talking around each other (which has already started, due to my misunderstanding).

The question is whether the problems...

1. occur in other applications for documents exported from Inkscape to plain SVG
2. and also do not occur when the original document is used in Inkscape.

The question is whether the problems occur for exported files used in other applications but not inside Inkscape.

Are the issues you described in relation to exporting documents, or are they more general?

It's fine. I think it would be helpful if you try to create a comprehensive list, as far as your own knowledge will carry you, and then post the items along with brief explanations.

You probably cover all these details as well: stroke-styles where there are none needed, but CSS will not intervene, obstructing namespace-designators, mouse-sensitive zone around hyperlinks and so on.

If you are aware of further special cases or fringe cases relevant to the topic, then I would suggest listing as many as you know.

Yes, it would require soliciting suggestions from application developers. Ultimately, however, the cooperative use of the fields by various applications depends on central coordination of their definitions. Thus, the idea would be for the libvirt project to organize an official schema for metadata, to complement any other schemas that may be used in particular applications.

Allowing integration of such kind is among the strengths of libvirt, and I agree that direct use of QEMU by an application such as Vagrant would represent an overall regression away from more successful integration.

Host environment

• Operating system: Linux Mint 21
• Kernel version: Linux 6.0.5
• Architecture: x86-64
• QEMU flavor: qemu-system-x86_64
• QEMU version: 6.2.0
• Libvirt domain: See below.

Emulated/Virtualized environment

• Operating system: OpenIndian (Hipster) 2021-10
• Architecture: x86-64

Problem

See below.

Steps to reproduce

1. Acquire installation media from download site (file: OI-hipster-minimal-20211031.iso, SHA-256 sum: 7a58b93987d7febeb16b5aa38b62f2e685aed66eb27896d31396d4710f956876).
2. Install libvirt domain.
3. Start guest.
4. Proceed with default boot selection, or simply wait for timeout at menu.

Additional information

I am not experienced in QEMU, and have not been able to isolate with a simple command line. However, I will attempt any test cases provided by the community.

The problem in the domain reproduced below resolves by removing the SATA optical drive (even if the SATA controller remains).

The working case may be derived through the following patch:

1c1
< <domain type='kvm' id='83'>
---
> <domain type='kvm' id='82'>
18a19
>     <boot dev='hd'/>
42c43
<       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='2'/>
---
>       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='1'/>
46d46
<       <boot order='1'/>
48,54d47
<       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
<     </disk>
<     <disk type='file' device='cdrom'>
<       <driver name='qemu'/>
<       <target dev='sda' bus='sata'/>
<       <readonly/>
<       <alias name='sata0-0-0'/>

For consistency, the boot media is installed on an IDE optical drive, which appears not to cause problems. The problem was originally discovered attempting to boot from a SATA optical drive, following the intended layout of the guest system.

<domain type='kvm' id='84'>
  <name>openindiana-clone</name>
  <uuid>7a0550ec-ff03-4894-80b8-affe0dfd8177</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://oracle.com/solaris/11"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>4</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana-clone_VARS.fd</nvram>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'/>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='2'/>
      <backingStore/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <alias name='sata0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='ide' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='sata' index='0'>
      <alias name='sata0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <input type='mouse' bus='ps2'>
      <alias name='input0'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input1'/>
    </input>
    <graphics type='spice'>
      <listen type='none'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    <audio id='1' type='spice'/>
    <video>
      <model type='vga' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='apparmor' relabel='yes'>
    <label>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</label>
    <imagelabel>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</imagelabel>
  </seclabel>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+64055:+130</label>
    <imagelabel>+64055:+130</imagelabel>
  </seclabel>
</domain>

The issues is that the shutdown sequence followed by Windows is different depending on the way that the event was invoked, for example, whether through internal user action (system menu) or external hardware (power button). (Perhaps this difference is captured in the reference to InitiateSystemShutdownEx.)

When a host administrative operation invokes a system shutdown for a QEMU guest, it does not currently use the emulated hardware power interface, but rather triggers an action with the Guest Agent, which currently is invoking the sequence that Windows uses when the shutdown was prompted by a user sitting at the console.

This choice is leading to undesired behaviors.

When a shutdown operation is prompted remotely (which includes by the physical host whenever the same user is not directly interacting with the guest console), the guest should not wait for user response on the console, but should act just as though a hardware power event had occurred.

One possibility is to deprecate the shutdown command in the GA, in favor of ACPI events, which would be further helpful by adding compatibility with guests not running a GA, including guests that have not properly completed a boot cycle.

If such a change is too drastic, or not desirable, then the GA might simply try a system call that would trigger a more streamlined shut down sequence, if possible. Finally, the guest GA interface might be extended by an option that would indicate to the GA whether a user was interacting directly with the guest console, to determine whether to wait for user response or continue without.

For remote administration, it is not feasible or even possible in all cases for a user to interact directly with the console. Meanwhile, I am running a Windows guest under libvirt, which attempts to shut down guests as part of the host shutdown sequence. In this case, the host shutdown sequence often remains suspended after the host console is destroyed, making it completely impossible to respond to any user prompt generated on the guest console. Libvirt and QEMU do not currently agree on a set of assumptions governing guest behavior throughout the life cycle of host boot session, and addressing these incompatibilities probably depends on more careful design, if not also richer vocabulary, from the GA.

I do not necessarily believe that a timer in the GA is the best solution, because the guest OS should be designed to handle remote shutdown requests appropriately. The choice to use a timer is one most appropriate as one internal to the guest OS, not added by the resident GA.

Host environment

• Operating system: Linux Mint 21
• OS/kernel version: Linux 6.0.1-060001-generic #202210120833
• Architecture: x86 64-bit
• QEMU flavor: x86_64
• QEMU version: 6.2.0
• QEMU command

Emulated/Virtualized environment

• Operating system: Windows 11
• Architecture: x86_86

Description of problem

When a user of a system initiates a system shutdown operation directly through the system desktop, it is appropriate for open applications to prompt the user for a response, if the applications remain in a state without work having been saved to storage.

However, when the operation is initiated remotely, as through the monitor, or indirectly through the management operations provided by libvirt, or other management utilities, then user intervention is infeasible. In such cases the effect of the user prompt is simply to prevent a graceful shutdown as initiated by the host or an administrative remote client.

Steps to reproduce

1. Open notepad on Windows (11) guest.
2. Type text. Do not save to file.
3. Attempt shutdown through monitor.
4. Guest shutdown waits for user response.

Additional information

The shutdown operation triggered by the Windows Guest Agent should prevent the system from waiting for a user response concerning unsaved work of open desktop applications. Instead, applications and services should be closed as gracefully as possible automatically, in advance of the power down event on the emulated hardware.

Virtiofs is supported in Windows through WinFSP.

User name mapping would be a convenient feature, which would require support on the guest side specialized to the OS. It seems also possible in principle for the mapping to be managed in the hypervisor configuration by transferring the mapping table to the active guest. Such a feature certainly would be an added convenience for many use cases.

Mapping UIDs directly, or mapping a range, may be handy for certain scenarios, but maintaining an alignment of numeric IDs is not always feasible.

Also note, as I reread some responses, it appears that they are specific for Linux guests, whereas the feature is equally valuable for guests of other operating systems, such as Windows, in which mapping UIDs may be less natural than between two systems of POSIX design.

I forgot to mention that you can also use BindFS or id mapped mounts [0] on top (or under) virtiofsd

For considering the proposed feature, the principle I have followed is that the essential idea of virtiofs is to expose files on the host to the guest, available for guest applications, as though they were files on the same machine, but without the baggage of network file systems. It follows this principle to consider a scheme for mimicking the file permissions of these files as they are exposed to the guest.

The fuse protocol needs to send us the username of the process accessing the file, currently we only see the uid and gid

Yes, I completely understand: the fuse protocol, if it may be extended as such, or another connection operating in tandem.

Toward a more general discussion, I might suggest that as virtio reaches a state of maturity for the core, low-level functionality, it becomes increasingly valuable to consider how the functionality may be complemented by higher-level features that improve support for practical case. I am reminded of recently finding the archived documentation of a project for automatically adjusting the memory balloon for guests by evaluating the relative need for physical memory on either side. Unfortunately, the project was shelved almost a decade ago, even while the demand for such a feature seems to remain as great as it had ever been.

Yes, but is not always the case, I don't think is even the most common case. Usually you don't trust the guest.

Both cases are common in my experience. Many VMs are accessed by users as regular machines in the same domain, in which the distinction between administrator and regular user is the same throughout.

It is true of course that one of the uses of a VM is to give some user full access to a machine in the host, but not the host itself.

That requires a lot of changes not only in the virtiofsd, but also in the kernel side

It would require user space tools to resolve the mapping and to transfer it to the kernel.

If all users of the guest have administrative access to it, then the scheme may compromise the host. The useful case is one in which the administrator provisions the guest and host, and wants regular users to access files from the guest with the same permissions as from the host. If a mapping of user names is given, it would probably be more helpful if specified on the host.

Yes. The proposed change as I intended is not one such that the guest may make an arbitrary mapping of its users to the host's, to acquire unrestricted access to the host.