Page 7 of 8

Posted: Wed 10 Sep 2014, 17:01
by mikeb
Hmm well thinking about it perhaps a checkbox would not hurt....just don't want to get too cluttered.

Alternatively adding the info to a tooltip would be neat plus as I found there are several audio options available which I assume affect what is used on the host rather than the emulated card.

I feel an update coming on.

mike

default bootup

Posted: Mon 06 Oct 2014, 18:46
by DC
Hi mikeb,
A small request for the QEMU launcher.
Could you make the boot option default to last used or default selectable.
As at the moment it defaults to Primary harddrive which I always forget and have to start again selecting cd/dvd.

thanks

dc

Posted: Mon 06 Oct 2014, 20:04
by mikeb
As at the moment it defaults to Primary harddrive which I always forget and have to start again selecting cd/dvd.
hmm a little odd as currently if there is no hard drive image given then it falls back to booting the cd/dvd anyway.

Needs seem to vary on this one...perhaps last chosen might be a suitable compromise.

mike

Posted: Tue 07 Oct 2014, 05:47
by DC
Hi Mike,
Thanks for the swift reply. I do have a hard drive image, which I use as a common drive when testing different ISO's
Maybe I need to read up on how to access physical drives outside of virtual ones.

dc

Posted: Tue 07 Oct 2014, 06:04
by gcmartin
I like two thoughts, either of which are useful.
  • last chosen
  • save current QEMU config (for a future selection when launching)
Either of these would be great.

Posted: Tue 07 Oct 2014, 09:50
by mikeb
Ok I think last chosen makes the most sense then it follows whatever the users preferred arrangement is...i can still leave the fall back in regardless.

To use a real image you can make a symlink to the actual drive (hda...sda..and so on...NOT sda1..you need the whole drive not a partition for this to make sense) and call is anewname.img .... the .img is important to get it recognised.
I do this all the time to use usb sticks and it can be used for real hard drives too. Bear in mind whatever you boot will see a qemu machine so an existing windows install would change over drivers and it might get upset when you boot the real machine...do it at your own risk and use common sense.

mike

Posted: Tue 07 Oct 2014, 14:34
by gcmartin
Hello @DC
DC wrote:I do have a hard drive image, which I use as a common drive when testing different ISO's
Maybe I need to read up on how to access physical drives outside of virtual ones.
I would like to share a manner of view which might be helpful.

In todays technology of QEMU there is the concept of the your main running machine (the host) and the virtual machine (the Guests). The main machines have always used drives directly, while the virtual machines (guests) use a virtual drive (which is a file formatted to look like a drive to any guest).

You share that you have "a hard drive image". If so, that image CAN be used by the virtual guest machine if its in the proper format. For example, if I have Puppy/Linux/Windows system operational on a HDD partition, I can "dd" that partition and boot a guest where that partition can be restored to a guest's HDD partition. Then, I can use that guest in exactly the same way it was used before, excepting now, its running in the virtual guest. In other words, I can then shutdown that guest configuration and reboot that guest targeting the new partition (assuming it was bootable before) via the QEMU LAUNCHER options.

This is one way to use the image you mention in your guest's needs.

Hope this helps

Posted: Wed 08 Oct 2014, 16:41
by DC
Hi mikeb,

Thanks for the symlink info,
Here's what I did for anybody else thats a bit confused.
First I tried to symlink the sdb1 directory in /mnt that does not work its a directory!
Then tried the file in /dev for sdb1, symlink renamed vsdb1.img that seemed to work so so. Then I read the instructions again :oops:
This time symlink to sdb, renamed vsdb.img. This works ok.
One thing I noticed is if you have the usb sdb1 mounted normally then the contents can show different to the drive inside the virtual pc. Is there a way to sync this?

Hi gcmartin,

Similar to what you described, Many years ago I used PartitionMagic to make a image of a windows system to retrieve corrupted data. Mounting it in a vmware VM. Worked well though it took hours.

The harddrive image I use as a common virtual drive for testing ISO's was just created to play with qemu and I forgot it was in the parameters of the qemu launcher when I first booted an ISO and noticed it was there on the virtual desktop :D

thanks
dc

Posted: Wed 08 Oct 2014, 17:40
by mikeb
One thing I noticed is if you have the usb sdb1 mounted normally then the contents can show different to the drive inside the virtual pc. Is there a way to sync this?
ah well accessing a drive loaded and in use by QEMU is supposed to be a big no-no... it may work but as you notice what happens in the virtual will not necessarily happen in the real and vice versa.

The 'approved' way would be to use such as NFS, sshfs or samba to mount a network share....

I believe virtualbox does allow partition sharing and in that it differs from QEMU....but things may have changed...ie it may be an option now.

mike

Posted: Wed 08 Oct 2014, 18:24
by Gobbi
Using qemu 2.1 from the terminal and trying to add sound card : an error gave me the choices seen in the screenshot below .

From all , only hda , es1370 and ac97 worked in my case . Using hdmi from my AMD videocard on TV , both sounds from host and guest came through hdmi channel .
With Realtek soundcard from the motherboard I used only headphones and good sound came only from one of the three - es1370 . The other two gave audio , but there were distorsions ... I'll try to see if I can pull different audio for host and guest from different outputs...
An aditional choice for soundcard in the GUI - if possible - would help the user ...

Posted: Wed 08 Oct 2014, 18:35
by mikeb
An aditional choice for soundcard in the GUI - if possible - would help the user
Well the suggestion so far was
Qemu_gui could set QEMU_SOUCE_DRV=alsa and leave it to the user to add additional parameters to effectively enable HD audio (perhaps a tool tip could remind of which parameters).
in otherwords you choose the soundcard manually rather than have a selection...a bit of a grey area since this seems to involve system variations as to what config is needed.

If there is a difinative range of sound configs I could work with that would help...I cannot test any of this myself.

mike

Posted: Wed 08 Oct 2014, 21:16
by Gobbi
I read the -audio-help in qemu and I also think the suggestion mentioned above would be a good one :!:

Posted: Thu 09 Oct 2014, 08:58
by stemsee
@mikeB

Would it also be possible to specify which input device gets grabbed. Such as xinput Master second ?

Posted: Thu 09 Oct 2014, 10:15
by mikeb
I read the -audio-help in qemu and I also think the suggestion mentioned above would be a good one
which one?
Would it also be possible to specify which input device gets grabbed. Such as xinput Master second ?
don't know ask QEMU on their website.

Again I cannot test any of this really so would need a list of working combinations otherwise the 'diy and give info' approach will be the way...I could output the -audio-help to a text box like I do for handbrake.

mike

Posted: Fri 10 Oct 2014, 09:27
by Gobbi
mikeb wrote:I am also guessing that adding the QEMU_SOUND_DRV=alsa by itself may not...ie it could be made permanent with no detriment to users not needing sound...is this a decent bit of guesswork on my behalf? In which case the option is simply up to the user via the additional parameters without having to resort to the command line.
This is the suggestion I agree with , after I saw the output of typing qemu-system-x86_64 -audio-help in the terminal .

Posted: Sat 11 Oct 2014, 16:16
by mikeb
Thanks Gobbi for clearing that up...so add the global variable and give some sort of info box..

Well will get on with that and the other suggestion for boot device shortly.

mike

Posted: Mon 13 Oct 2014, 12:16
by Gobbi
You are welcome mikeb ! I'm glad to help somehow ...

Also , on jamesbond's suggestion , I added -sdl parameter ( using Qemu from the terminal ) and the geometry of the guest desktop follows the window's one . A checkbox for this option would add one more feature , I think .

Posted: Mon 13 Oct 2014, 12:34
by mikeb
-sdl... i noticed the -noframe related one and others.....

Bit awkward for testing here..... makes it not in its own window?#

Ie is there a set of parameters to give a particular feature? ... what exactly does only -sdl do... match windows borders?

mike

Posted: Tue 14 Oct 2014, 10:04
by Gobbi
mikeb wrote:what exactly does only -sdl do... match windows borders?
From what I've seen , yes .
Maybe this library should be included by default , at least for this reason .
Additional parameters come only with -display sdl option , as I read in qemu-system-x86_64 -sdl --help in terminal ...

Posted: Tue 14 Oct 2014, 10:15
by mikeb
Well I was wondering if there was a group of parameters to produce a desirable result...eg something akin to remote X where the virtual machine is transparent...in other words if we have a checkbox lets make the most of it :)

I also am making the assumption we would have SDL enabled when compiled which seems to be the case for what's floating around.

I will see if I can get something running to play with this myself too...even with a workable distro I don't have any kernel acceleration with the latest releases so tends to run like sludge.

mike