Re: autostart sessiioned vms
On 8/26/24 19:33, daggs wrote: > Greetings Michal, > >> Sent: Monday, August 26, 2024 at 11:52 AM >> From: "Michal Prívozník" >> To: "daggs" , users@lists.libvirt.org >> Subject: Re: autostart sessiioned vms >> >> On 8/23/24 14:23, daggs via Users wrote: >>> Greetings, >>> >>> I'm running sessioned vms which I want to start them up at boot. >>> I've marked a vm inside a use as autostart, added libvirtd to the boot >>> order and rebooted but it didn't started the vm. >>> I tried adding libvirt-guests to bott services but my sessioned vm is still >>> not autostarting. >>> what is the proper way to do so? >> >> There are two modes of operation: >> >> 1) qemu:///system >> 2) qemu:///session >> >> The former runs a system-wide VMs, the latter runs per-user VMs. The >> former runs libvirtd under root, the latter runs libvirtd under given >> user. If you enable libvirtd at startup, it's very likely that you're >> starting the system-wide instance (i.e. qemu:///system). >> >> Usually, per-user daemons (like dbus, pipewire) are started after user >> logs in. That's where you want to place libvirtd start too. I'm not sure >> what init system you're using, but perhaps it has a way to start a >> per-user service - consult documentation to your init system. >> >> BTW: user daemon is started automatically upon connection opening. For >> instance, running the following starts a session daemon: >> >> $ virsh uri >> >> Oh, and if you're using autostart for other objects than domains, then >> you need to start corresponding daemons. >> >> Michal >> >> > > I'm using openrc. > so based on the above, if I login as the user where the vm is defined, it > should start it? If you configure your session manager then yes. For instance, I'm using KDE and I can configure what files should be executed after login. > what happens if I log out from the user? the vm stays up? Yes, the daemon won't die unless there's no VM running and no client connected for 120 seconds (by default). Michal
Re: autostart sessiioned vms
> Sent: Tuesday, August 27, 2024 at 10:34 AM > From: "Michal Prívozník" > To: "daggs" > Cc: users@lists.libvirt.org > Subject: Re: autostart sessiioned vms > > On 8/26/24 19:33, daggs wrote: > > Greetings Michal, > > > >> Sent: Monday, August 26, 2024 at 11:52 AM > >> From: "Michal Prívozník" > >> To: "daggs" , users@lists.libvirt.org > >> Subject: Re: autostart sessiioned vms > >> > >> On 8/23/24 14:23, daggs via Users wrote: > >>> Greetings, > >>> > >>> I'm running sessioned vms which I want to start them up at boot. > >>> I've marked a vm inside a use as autostart, added libvirtd to the boot > >>> order and rebooted but it didn't started the vm. > >>> I tried adding libvirt-guests to bott services but my sessioned vm is > >>> still not autostarting. > >>> what is the proper way to do so? > >> > >> There are two modes of operation: > >> > >> 1) qemu:///system > >> 2) qemu:///session > >> > >> The former runs a system-wide VMs, the latter runs per-user VMs. The > >> former runs libvirtd under root, the latter runs libvirtd under given > >> user. If you enable libvirtd at startup, it's very likely that you're > >> starting the system-wide instance (i.e. qemu:///system). > >> > >> Usually, per-user daemons (like dbus, pipewire) are started after user > >> logs in. That's where you want to place libvirtd start too. I'm not sure > >> what init system you're using, but perhaps it has a way to start a > >> per-user service - consult documentation to your init system. > >> > >> BTW: user daemon is started automatically upon connection opening. For > >> instance, running the following starts a session daemon: > >> > >> $ virsh uri > >> > >> Oh, and if you're using autostart for other objects than domains, then > >> you need to start corresponding daemons. > >> > >> Michal > >> > >> > > > > I'm using openrc. > > so based on the above, if I login as the user where the vm is defined, it > > should start it? > > If you configure your session manager then yes. For instance, I'm using > KDE and I can configure what files should be executed after login. > that system uses only cli, I need the vms to start at boot > > what happens if I log out from the user? the vm stays up? > > Yes, the daemon won't die unless there's no VM running and no client > connected for 120 seconds (by default). what do you mean by "client" > > Michal > >
KVM Fails 3D Acceleration on Debian (failed to validate against schema)
Full VM xml: ``` Whonix-Gateway c011d3d3-8383-47a8-b2cd-d54f883d8af1 bc5b233c-46ea-4bfb-ad99-00f1165a09e6 Do not change any settings if you do not understand the consequences! Learn more: https://www.whonix.org/wiki/KVM#XML_Settings 125 125 250 1 hvm destroy restart restart /usr/bin/qemu-system-x86_64 /dev/random ``` But it will always show: ``` error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Extra element devices in interleave Element domain failed to validate content ``` Any idea how to resolve this?
Re: KVM Fails 3D Acceleration on Debian (failed to validate against schema)
On Tue, Aug 27, 2024 at 21:36:29 -, bo0od--- via Users wrote:
> Full VM xml:
>
> ```
[...]
>
>
>
>function='0x0'/>
>
>
>
>
>
>
>
> /dev/random
>function='0x0'/>
>
>
>
> ```
>
> But it will always show:
>
> ```
> error: XML document failed to validate against schema: Unable to validate doc
> against /usr/share/libvirt/schemas/domain.rng
> Extra element devices in interleave
> Element domain failed to validate content
> ```
>
> Any idea how to resolve this?
Error from a XML validator with more reasonable error reporting is:
/tmp/asdfasdf.xml:134:50: error: element "acceleration" not allowed here;
expected the element end-tag or element "acpi", "alias" or "driver"
/tmp/asdfasdf.xml:135:25: error: element "gl" not allowed here; expected the
element end-tag or element "acpi", "alias" or "driver"
Per https://www.libvirt.org/formatdomain.html#video-devices
The '
And '' like this it validates properly:
Although I don't know where you got that definition because the qemu
driver doesn't support 'accel2d' altogether:
$ virsh define /tmp/asdfasdf.xml
error: Failed to define domain from /tmp/asdfasdf.xml
error: unsupported configuration: qemu does not support the accel2d setting
In src/qemu/qemu_validate.c in the function qemuValidateDomainDeviceDefVideo()
the check is as follows:
if (video->accel && video->accel->accel2d == VIR_TRISTATE_BOOL_YES) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("qemu does not support the accel2d setting"));
return -1;
}
Thus with no exception.
Thus the final working 'video' is:
Which is accepted:
$ virsh define /tmp/asdfasdf.xml
Domain 'Whonix-Gateway' defined from /tmp/asdfasdf.xml
