Hello.
During the installation phase I opted to make sys-net persistent. I’d like to change that so it’s a disposable.
There is documentation but about making a new sys-net qube.
How can I convert the existing qube to a disposable?
I tried qvm-prefs <name> template fedora-36-dvm but learned it doesn’t work the way I intended.
I don’t know if what I am about to describe will actually work, but it’s what I would try. Proceed at your own risk, and before starting back up your network qube.
I am assuming the qube you tried renaming is NOT a templateVm but rather an AppVM based on a template VM.
A disposable template is basically the same as a persistent app qube, except that on the second page of settings (advanced), the box for “Disposable Template” has been checked. You have to check that. Then hit “apply” before the next step.
If you want to rename the qube so it ends in dvm (not a bad idea), go back to the basic tab in Settings, and press the “Rename” button. Add -dvm to it. (Note if there are any other unsaved changes they will go away when you do this, which is why I told you to apply the previous change before coming to this step.)
One more step, you probably want your disposable to have the same name always; for that you will want “new qube”, and select disposableVM for type. What should come out of this is a new qube that can serve as sys-net.
BUT BEFORE DOING ANY OF THIS clone your original qube to -BAK just in case none of this works. And you will have to shut down your net qube before doing any of this.
Oh, and I forgot to mention you should back up your present qube before making any changes to it, just in case.
I managed to make it work my own way. Here it is.
Just edited the file /var/lib/qubes/qubes.xml so sys-net has the class “DispVM”, the propery “dispid” set to a unique value and its property “template” set to fedora-36-dvm.
Then restarted my computer and it works just as I wanted 
It’s entirely possible that what I suggested would have had the exact same result. I just was hesitant to go around the tools.
Good show!
What about converting back to persistent from disposable? Just reverse the above?
Perhaps this could help: Converting a disposable to a standard qube. Or, if you have no important data to save, you can just create a new AppVM, give the WiFi card to it and use it as sys-net.
Ironic that this thread should pop up when it did.
I have been converting over to salt to generate my templates, and decided at the same time to make sys-net a disposable. Or rather, I should say I decided to make sys-net-wifi a disposable (i.e., the sys-net that is dedicated to my wifi connection).
So far (though I haven’t tried everything) this looks like a bad idea. Wifi no longer automatically connects on startup because the disposable doesn’t remember the connection from last time.
I’ve found a command line to establish the connection (it includes my wifi password, but then, it was being saved in the old AppVM configuration anyway). The problem is I can’t get it to automatically execute…I’ve tried systemd and the older autoexecute file (I can’t remember the exact path), both have to be installed in the template. I can tell both files are running (because they ‘touch’ files in /home/user that I put in as debug), it’s just that the nmcli command is probably running “too early”–in other words the wifi card isn’t available to the system yet when these automatic-on-startup things happen.
So I have to open a terminal in sys-net-wifi and run that script manually, every time I restart sys-net-wifi, before I try to do anything on the internet. Or connect through the GUI and remember the password.
I have in mind a kind of kludgy way to get the command to operate a little bit later; if that doesn’t work when I try it tonight, it’s back to template+AppVm instead of template+dvm template+dvm.
I actually tried what Sven suggested in your quote last night (I thought of it on my own…wow maybe I’m not a total newbie any more)…but it didn’t work.
So now I’m figuring I must have made some elementary mistake doing that; I’ll try it again.
I also tried something like what’s suggested in your other link (again a sign I’m not a complete noob) and that too, didn’t work. Skimming that thread it appears others might have had problems with that solution as well. So…will try Sven out again. If that fails, I’ll try the loop waiting for the WiFi controller to become active.
This is a royal pain to deal with, because every time I rebuild these qubes to try something, I have to redirect my “stack” (sys-net-template, sys-net-dvm-template, sys-net itself) to clones of the normal vms, start sys-net up and make sure it’s connected to the internet for the build process because cacher gets involved installing things. Then switch back to test the new sys-net.
I would never, ever, ever, never connect online any qube that has template in it’s prefs/name, hahah. Actually, my default netVM is none.
Setup connection in sys-net dispVM and while it’s still on, fire up it’s dvm-template and copy correspondent .nmconnection from sys-net to
/rw/config/NM-system-connections
folder of a dvm-template. Shutdown both, and restart sys-net. That way, it’ll persist across reboots.
Luckily I was able to figure out how to get it done in a salt file without connecting the template.
It involves connecting the disposable template to the wifi controller briefly, but since that’s really an appvm anyway, that’s no worse than a non-disposable sys-net (which is an app vm) connecting to the internet…which it does, of course.
Would you share with us how you did it with Salt?
OK, it’s a bit ugly. Three separate salt files. They could probably all be called from one .top file.
The first needs to be run in the dom0 environment. This isn’t quite the file I used; I have a fairly elaborate process for setting up the names of the VMs–I’ve elided that, it’s not really relevant.
Basically, this first file takes the dvm template (deb11m-net-wifi-dvmt) and temporarily makes it an ordinary AppVM, but. Also the virtualization mode must be set to hvm since it’s going to diddle directly with a device, shortly.
After being made “not a template” the device is attached to deb11m-net-wifi-dvmt and “provides network” is set to true. So now, the erstwhile dvm-template is just like the normal sys-net.
{% if grains['nodename'] == 'dom0' %}
{% set namestem = 'net-wifi' %}
{% set vmname = 'deb11m-net-wifi-dvmt' %}
dvmt-{{namestem}}-detemplatize:
qvm.prefs:
- name: {{vmname}}
- template_for_dispvms: false
- virt_mode: hvm
{% set ndevices = salt['cmd.shell']('qvm-pci ls ' + vmname + ' | wc -l') %}
{% if ndevices != '1' %}
dvm-{{namestem}}-devices-attach:
cmd.run:
- name: 'qvm-pci attach --persistent {{vmname}} dom0:00_14.3'
{% endif %}
dvm-{{namestem}}-provides-network-true:
cmd.run:
- name: 'qvm-prefs {{vmname}} provides_network True'
{% endif %}
This next one needs to be run on target deb11m-net-wifi-dvmt (change the name of course if yours is named something different).
The first thing it does is pause for a couple of seconds. That’s because it takes a short amount of time for the wifi adapter to actually kick on. Without this delay there will simply be a nasty error message and an exit.
Then start the network manager, now that it has a wifi controller to talk to.
But it still takes some time before connecting the two, so another delay.
Then connect to the driver. After this, the appvm named deb11m-net-wifi-dvmt shuts down, knowing
how to connect to the wifi controller.
{% set namestem = 'net-wifi' %}
{% set vmname = 'deb11m-net-wifi-dvmt' %}
{% if grains['nodename'] == vmname %}
dvmt-{{namestem}}-start-network-manager-wait-first:
cmd.run:
- name: 'sleep 2'
- order: 1
dvmt-{{namestem}}-start-network-manager:
cmd.run:
- name: '/sbin/NetworkManager'
- order: 2
dvmt-{{namestem}}-connect-to-wifi-wait-first:
cmd.run:
- name: 'sleep 15'
- order: 3
dvmt-{{namestem}}-connect-to-wifi:
cmd.run:
- name: 'nmcli d wifi connect TMOBILE-9855 password XXXXXXXXXXX'
- order: 4
{% endif %}
The next salt file simply reverses the first one, turning off provides network, resetting the virtual mode, making the VM a dvm template. However, since this runs in dom0, it must wait for the net qube to shut down.
{% if grains['nodename'] == 'dom0' %}
{% set namestem = 'net-wifi' %}
{% set vmname = deb11m-net-wifi-dvmt' %}
dvm-{{namestem}}-shut-down-train:
cmd.run:
- name: 'qvm-shutdown --wait {{vmname}}'
dvm-{{namestem}}-provides-network-false:
cmd.run:
- name: 'qvm-prefs {{vmname}} provides_network False'
dvm-{{namestem}}-devices-detach-train:
cmd.run:
- name: 'qvm-pci detach {{vmname}} dom0:00_14.3'
dvmt-{{namestem}}-dvmt-unprefs-train:
qvm.prefs:
- name: {{vmname}}
- template_for_dispvms: true
- virt_mode: pvh
{% endif %}
You don’t need to “temporarily makes it an ordinary AppVM” - it is an
ordinary appVM.
The detemplateizing is unnecessary.