SpaceInvaderOne

Heres a guide showing how to mount any vdisk on your server. Wether you just dont want to boot the vm and login to get to the data or your vm just doesnt boot anymore, then heres how to mount the vdisks straight from the server.

So do you ever need to access a vdisk but dont want to , or cant start the vm. Well we can using qemu-nbd. This video shows how to use that and mount a vdisk. Also see how to fix ntfs disks when not 'clean' and so set to read only. Happen when vm not shutdown correctly. Also in the video there are some scripts which will mount and unmount the vdisks very easily. hope some of you out there find it useful

So evdev passthrough is used for passing through a keyboard and mouse to a vm. Yep we can easily do this by just passing through the usb device. However this works slightly differently. As well as having extremely low latency, it allows us to passthough any keyboard or mouse. That includes UBS and the old PS2 devices. Hit both control keys and the input will switch between the host and vm on the fly. If you like running old operating systems as vms the evdev is for you. Some old systems dont support usb. So using evdev you can still pass it through to those old systems. Hope you find this useful

Yes the extra variables in the template may need you to delete the old template from the server so the new one is pulled down from community applications if on updating the container it doesnt change. So you have filled in the 2 variables driver capabilities to all and the id number of your gpu from the nvidia plugin. But you didnt say if you set the extra parameter (advanced view) to --runtime=nvidia If all these are set then please post screen shots of how the template is filled in.

Update to the container. Changing tag to :nvidia will allow you to use you nvidia gpu with the container. Thankyou @gshlomi for your message regarding this. There are some changes to the template too which should be updated in the com apps feed in the next hour or two. Details are now at the beginning of this post.

Having had a few flashdrives fail over the years and all reviews i see online regarding flash drives seem to only care about speed, size and price I thought i would test 27 flash drives to find the most reliable one that i could.

I find the easiest way to move to a larger disk is not expanding the existing disk but to migrate to a new disk instead. 1. Create new macOS vm with larger disk. (ie 200G) 2. Stop new VM 3. Add the old macOS vm's vdisk (100g disk) as an additional disk to the new vm in its template. 4. Boot into new vm 5. Run migration assistant (applications/utilities/migration assistant) 6. Now you can migrate all programmes data and settings from the old vdisk to the new larger vdisk 7. After migration complete shutdown vm. 8 Remove old vdisk from template 9. delete old vdisk or keep as backup.

Hi, I think it would be really great to be able to set individual mover schedules that are specific to each cache pool. As i would find it useful to have some pools move files more often than others.

Ah i was writing the reply when you posted this. Glad its working for you

Ah its an easy mistake to make , I have done the same before myself many times before You can change the grafana port or the rocket chat port. If you change the rocket chat port you will have to make a change in reverse proxy config file too as the confile file expects the port that Rocket chat is using to be 3000. So its this bit here you would need to change. server { listen 443 ssl; server_name rocketchat.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { resolver 127.0.0.11 valid=30s; set $upstream_app Rocket.Chat; set $upstream_port 3000; <<<<<<<<<<<<<<<<<<<<<<<<you would have to change the port here to match whats specified in the template>>>>>>> set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto http; proxy_set_header X-Nginx-Proxy true; proxy_redirect off; } } server { listen 80; server_name rocket.*; return 301 https://$host$request_uri; }

So you get an error like this when you click on start for the container? Most likely you have another container running with the same port in use. Is anything else using port 3000? Grafana also uses port 3000 by default.

Here is a guide showing how to setup Rocket chat running through a reverse proxy. Also you can update the container but when you setup the mongoDB you must specify the hostname in the container when you create it. That way when the container is ever recreated it keeps the same name and so doesnt cause the database to break. If you already have rocket chat installed and have disabled updates then see a fix that will allow you to update as normal at the end of my video.