суббота, 19 мая 2018 г., 16:37:55 UTC+3 пользователь Qubes Guy написал:
> On Saturday, May 19, 2018 at 4:23:09 AM UTC-4, David Hobach wrote:
> > On 05/19/2018 01:04 AM, Qubes Guy wrote:
> > > On Friday, May 18, 2018 at 5:59:09 PM UTC-4, David Hobach wrote:
> > >> On 05/18/2018 08:19 PM, Marek Marczykowski-Górecki wrote:
> > >>> -----BEGIN PGP SIGNED MESSAGE-----
> > >>> Hash: SHA256
> > >>>
> > >>> On Thu, May 17, 2018 at 05:57:09PM -0700, Qubes Guy wrote:
> > >>>> I've successfully used qvm-block (in Dom0) to attach USB drives to 
> > >>>> different VMs (persistently), but I've noticed that Qubes (or Linux) 
> > >>>> sometimes gives them to different devices over time. In other words, 
> > >>>> on Monday, my BIG_TOSHIBA drive will be on /dev/sda, but it'll be 
> > >>>> assigned to /dev/sdj when I boot up on Wednesday. This is throwing off 
> > >>>> my VeraCrypt / FreeFileSync backup routine. (Another way of saying 
> > >>>> this is if I say "qvm-block attach MyVM sys-usb:sda --persistent" when 
> > >>>> one of the three drives I use for MyVM is currently attached to that, 
> > >>>> this will fail if Qubes moves that drive to a different device-name 
> > >>>> (during boot) that isn't one of the three I previously attached (when 
> > >>>> I go to start up that VM).
> > >>>>
> > >>>> I thought about persistently attaching all 10 of my USB drives to the 
> > >>>> VM (some HDs, some flash, one SSD - I never use all of them at once - 
> > >>>> don't ask!) because that would certainly fix this problem, but I get 
> > >>>> the following error when I try to start the VM: "ERROR: Start failed: 
> > >>>> XML error: target 'xvdi' duplicated for disk sources '/dev/sdc' and 
> > >>>> '/dev/sde', see /var/log/libvirt/libxl/libxl-driver.log for details".
> > >>>>
> > >>>> Note that I did all the persistent attachment commands while the VM 
> > >>>> was not running. If I detach all those, start the VM, do the 
> > >>>> persistent attachments, shut down the VM and then restart it, I get an 
> > >>>> error along the lines of "qrexec process failed to respond in 60 
> > >>>> seconds".
> > >>>>
> > >>>> So, I guess I'm asking if there's a way to just persistently attach 2 
> > >>>> or 3 external USB drives and have them consistently available on the 
> > >>>> same device names when I start the VM so VeraCrypt doesn't balk?  
> > >>>> (VeraCrypt ultimately doesn't care what device a drive is attached to 
> > >>>> (it could be sda - sdj on my system) because it shows the attached 
> > >>>> drive as "/media/user/BIG_TOSHIBA, but if a drive isn't where it's 
> > >>>> supposed to be, that'll fail.
> > >>>>
> > >>>> In case you're curious, the error messages in 
> > >>>> /var/log/libvirt/libxl/libxl-driver.log are meaningless to me, but if 
> > >>>> you want me to post it, I can.
> > >>>>
> > >>>> Any help you guys can give me would be greatly appreciated! Thanks...
> > >>>
> > >>> It isn't available yet, related issue:
> > >>> https://github.com/QubesOS/qubes-issues/issues/3437
> > >>
> > >> As a workaround you could mount the device via uuid or file system label
> > >> in sys-usb, create a loop device from the container you want to pass to
> > >> another VM and use qvm-block on that loop device (for which you can
> > >> define the name yourself).
> > >>
> > >> Of course that's only convenient if you script it...
> > > 
> > > Thanks, but how do you do create a loop device? I'm (mostly) a Linux 
> > > newbie (and, as of 5 weeks ago, I was a Qubes newbie) - I'm your worst 
> > > nightmare :)  I tried the UUID mount thing described in the article I 
> > > mentioned above, but it just prevents sys-net from starting, but maybe 
> > > with this loop thing you mention? Can you give me the actual commands 
> > > required, or direct me to an article showing this? I'm not even sure what 
> > > to search for. Thanks much!
> > 
> > Honestly you'll probably be off better by waiting for the feature to be 
> > implemented then.
> > 
> > Anyway for reference I was talking about something like
> > 
> > in your sys-usb:
> > 1. mount -U [uuid] [mount point]
> > 2. losetup -f --show [your veracrypt file on the mounted file system]
> > 
> > in dom0:
> > 3. qvm-block a [target VM] "sys-usb:[output of 2]"
> > 4. Open the veracrypt block device now attached to [target VM]. (luks 
> > supports that, not sure about veracrypt)
> > 
> > You can script all of that from dom0 using qvm-run. Essentially the idea 
> > was to attach the Veracrypt file to [target VM] instead of attaching the 
> > USB device itself.
> > 
> > qvm-block also supported files itself in 3.2 (i.e. 1. & 2. could be done 
> > with qvm-block), but from my experience that didn't work so well in the 
> > past.
> > In 4.0 it was then removed I think; qvm-block -p [target VM] [some file] 
> > would have made for some really interesting applications such as the one 
> > described above without much need for scripting.
> 
> Thank you. You might be right about waiting. I've already wasted too much 
> time on this, but I'll take a look at it :) Thanks again

how to connect USB to standalone VM kali linux?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fc044b9f-8f1b-4755-90f5-95f008163315%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to