casualsnek / cassowary

Run Windows Applications on Linux as if they are native, Use linux applications to launch files files located in windows vm without needing to install applications on vm. With easy to use configuration GUI
GNU General Public License v2.0
2.88k stars 75 forks source link

[Feature Request] Add support for multiple libvirt URIs #18

Open chqoot-vgxu opened 2 years ago

chqoot-vgxu commented 2 years ago

Normally libvirt has a default URI like 'qemu:///session' for users, I have the windows vm in the 'qemu:///system' URI. When the app starts it tryes to reconnect to the VM waking it up if needed, virsh searches the VM in the default (session) URI, doesn't find it and crashes the app. A simple workaround is to add LIBVIRT_DEFAULT_URI env variable pointing to the system one, but that becomes tedious very fast as it would have to be done for each windows application.

It would be nice to be able to configure one or even a list of URIs, this would give access even to libvirt managed VMs which are not local to the machine using remote URIs (es. qemu+ssh://remote@server/system), or to VM running on top of Xen.

casualsnek commented 2 years ago

I will consider adding option to configure LIBVIRT_DEFAULT_URI or --connect parameter for virsh in advanced section of application !

chqoot-vgxu commented 2 years ago

If it's ok with you I can try and add that, ever used pyqt though

casualsnek commented 2 years ago

If it's ok with you I can try and add that, ever used pyqt though

Sure, you can try and if you got it working send a PR!

Should be pretty easy, you can try adding a key for libvirt url to cfgvars.py's default configuration, Then you can open main.ui file located in 'src/cassowary/gui/components/qtui_files' in qt designer and add a label and text box then give them a name..

Open main_ui.py located in 'src/cassowary/gui/components/' directory, edit the populate_general function to write the current value to the GUI and save_vminfo function to allow saving ( Should be pretty easy). Then you can find wherever virsh is added and add "--connect", "cfgvars.config['your_key_in_config']" to the list of parameters ( preferably right after "virsh" before other parameters)

chqoot-vgxu commented 2 years ago

Nice thanks, I'll start working on a POC. One question, why are you using subprocess instead of using the libvirt python module?

casualsnek commented 2 years ago

Nice thanks, I'll start working on a POC. One question, why are you using subprocess instead of using the libvirt python module?

I really don't know why i did that 😅 , i had also noticed that and plan to replace them as i get time .

Update: I removed all subprocess calls to virsh and use libvirt-python, just need to test it and push the changes, i also added one configurable libvirt uri in GUI !

casualsnek commented 2 years ago

Not multiple libvirt uri, but i added option to configure libvirt URI in the latest release, also as you suggested i removed subprocess calls to virsh and moved to libvirt-python :)

Can you check the latest release and close the issue if you feel like the feature was added as you wanted !

chqoot-vgxu commented 2 years ago

I'll try as soon as I get back home from work. Don't worry about multiple URIs, thinking back it doesn't make much sense since cassowary can only handle one connection to one windows machine

chqoot-vgxu commented 2 years ago

Did some testing and it works great. Only one thing I noticed, in the code you open connections to libvirt but you never close them. You should either use con.close() or the with statement, preferably the latter

casualsnek commented 2 years ago

https://github.com/casualsnek/cassowary/commit/ae3959175323c49eaafa7646948eb25312bc0d3a With this commit the connection should be closed ( i used conn.close() even though with statement would have been better. I have plans to clean up code when it gets stable enough )

casualsnek commented 2 years ago

The v0.6 release should have the fix added, you can test if it works as expected !

chqoot-vgxu commented 2 years ago

Will do, but lately windows defender is acting up lately, thinking that cassowary.exe is a troyan and blocking it

casualsnek commented 2 years ago

Will do, but lately windows defender is acting up lately, thinking that cassowary.exe is a troyan and blocking it

This may have happened because latest build was done on wine instead of windows vm , you can try building it locally if you have issues :)

chqoot-vgxu commented 2 years ago

I'm back, I tried building it on my VM, and after some problems I managed to build everything, but the server doesn't want to start, no reports from windows defender though

casualsnek commented 2 years ago

I'm back, I tried building it on my VM, and after some problems I managed to build everything, but the server doesn't want to start, no reports from windows defender though

can you start the server application with command line and see it it throws any error and also check the logs for error

path\to\cassowary.exe -s to starr the server application !

Windows defender can create some issues so i recommend using setup.bat to install and run Cassowary server from C drive as setup adds firewall rule for Cassowary in C:\Program Files\cassowary\cassowary.exe