LVM container access from guest

[dentonesque]

I am unable to access an LVM container residing on a Linux host from within a Linux guest using VirtualBox file shares.

This USED TO WORK!

But I just upgraded my system. Now, after opening an LVM container on the host from the guest using "cryptsetup luksOpen", when I attempt to work with container (using, say, "pvdisplay"), I get the following:

Code: Select all

$ sudo pvdisplay
  /dev/loop0: read failed after 0 of 4096 at 131523870720: Input/output error
  /dev/loop0: read failed after 0 of 4096 at 131523928064: Input/output error
  /dev/loop0: read failed after 0 of 4096 at 0: Input/output error
  /dev/loop0: read failed after 0 of 4096 at 4096: Input/output error
  /dev/mapper/lvm_crypt_abc: read failed after 0 of 4096 at 0: Input/output error
  /dev/mapper/lvm_crypt_abc: read failed after 0 of 4096 at 131523870720: Input/output error
  /dev/mapper/lvm_crypt_abc: read failed after 0 of 4096 at 131523928064: Input/output error
  /dev/mapper/lvm_crypt_abc: read failed after 0 of 4096 at 4096: Input/output error

How to replicate:

Environment:
- Host: Mint 19.2 (Kernel 4.15.0-58, based on Ubuntu 18.04 / Bionic)
- Guest: Mint 19.2 (Kernel 4.15.0-58, based on Ubuntu 18.04 / Bionic)

On the host create a container file, open the container, create a physical volume within the container, then view the physical volume, and then close the container:

Code: Select all

sudo dd if=/dev/urandom bs=1M count=20 of=./container

sudo cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random --verify-passphrase --align-payload 0 luksFormat ./container

sudo cryptsetup luksOpen ./container lvm_crypt_abc

sudo pvcreate /dev/mapper/lvm_crypt_abc

sudo pvdisplay /dev/mapper/lvm_crypt_abc

sudo cryptsetup luksClose lvm_crypt_abc

Everything should work correctly.

Then, from the guest, open the container, view the physical volume, and then close the container.

Code: Select all

sudo cryptsetup luksOpen ./container lvm_crypt_abc

sudo pvdisplay /dev/mapper/lvm_crypt_abc

sudo cryptsetup luksClose lvm_crypt_abc

When calling "pvdisplay" you should see errors such as the "read failed" errors shown above.

This used to work just fine! In fact, when I use an old version of the guest running Mint 18.1 (Kernel 4.4.0-159), I am able to access and use the exact same LVM container on the host with no problem. (Host: Mint 19.2, Guest: Mint 18.1) Works great!

However, if I install the latest Guest Additions on the Mint 18.1 guest (i.e. upgrade from 5.1.38 to 5.2.32) I start having the same problems in the 18.1 guest as I do in the 19.2 guest.

I am at a loss for debugging this. Any help would be greatly appreciated!

Thanks!

[dentonesque]

I realize this is an unusual issue -- and it's a big "ask" -- but if there is anyone who can maybe give me some pointers here, I'd really appreciate it. I'm at a loss for how to resolve this issue -- or even identify where the issue is occurring. (If I could identify the latter, I'd be happy to create a bug report for a particular library, if that ends up being necessary.)

Also, if anyone is willing to maybe try these reproduction steps on any host/guest combination, I'd be very interested to know the results.

Thanks in advance!

[dentonesque]

I'm sorry to keep "bumping" this post, but I am at a complete loss for how to proceed

ANY SUGGESTIONS AT ALL would be very much appreciated!

Also, is there another forum that would be more appropriate for this?

Thanks.

[socratis]

I realize this is an unusual issue

I'd say too as well. That's why most probably you haven't had any answers so far.

But let's see if we can get to the heart of it, even though I have not in reality a real clue what you're talking about. Let's treat it as a generic problem, and deal later with the details.

This USED TO WORK!

That's a great start. Can you do a test matrix of what used to work? Different host kernel, guest kernel, VirtualBox versions? Can you rollback some of these and see where it starts failing and what's the culprit? First of all I would try the latest testbuilds and see if this has been addressed already.

I do have one Mint 19 host, but if it's something that's going to affect my host, I'd rather not try to replicate your setup, I like to keep my hosts as clean as possible. Plus I'm a Linux n00b, you'd have to hold my hand...

The most important step as I said would be to triage/bisect this and see what's failing, it might actually be a real issue that needs to be addressed. The more detailed your report, the better.

[fth0]

Also, if anyone is willing to maybe try these reproduction steps on any host/guest combination, I'd be very interested to know the results.

I'm interested in trying this, but the host I need for the test is not ready yet. I cannot promise anything, but maybe I can test it in a few days ...

[Martin]

Do I read your question correctly that you are trying to access a LVM container residing on the host filesystem through VirtualBox shared folders?
Then your were probably just lucky that it worked in older versions.
Shared folders are designed just for an easy way to transfer files between guest and host, not for active usage of files by programs inside the guest.

[dentonesque]

Thanks @socratis. That's great info. I'll be taking today to try and analyze the situation in more depth. I'll get back to you when I have some more info.

Thanks @fth0. I'd appreciate anything you can do. Thanks for the willingness to help.

Thanks @Martin. Yes, your understanding is correct. A couple comments about the "luck" aspect, though:

1. I do understand what you're saying, and it may well be "luck" (since it was not originally intended). However, it did work really well for years. There was no unreliability to it at all -- as one might expect from something being used outside of how it was designed. It was "rock solid"! And that makes me think it should be a relatively simple "fix" to give it back that ability.
2. It makes use of VirtualBox shared folders, however, once the LVM container is located, the file is being used as a block device from processes entirely running within the guest OS. That may, in a sense, make this approach more reliable than a "simpler" use case where someone actively works with multiple files that are part of the host file system. Make sense?

Anyway, thanks for the feedback everyone. I'm going to work on this more now and will let you know what I find out.

[dentonesque]

I am THRILLED to report that the problem is resolved!

When I was researching this previously -- and I did a lot of research! -- all of my searches typically contained the term "LVM". I think this may have eliminated some helpful results. Today I searched for "virtualbox shared folder block device" and found the following posts, which both seem to accurately describe my problem:

https://www.virtualbox.org/ticket/17360
viewtopic.php?f=3&t=86050&p=429494

The first post indicates that the bug was introduced in 5.2.x and resolved in 6.0.6. So I upgraded to 6.0.12, and the problem went away. (Previously I had only gone as high as 5.2.32, because that was the highest version in the Linux Mint repos.)

Thank you SO MUCH to everyone who responded and was willing to help me out!!! I really do appreciate it.

Have a great, wonderful, and glorious day!

[socratis]

Ah, the "loop device" bug! Didn't/couldn't make the connection with what you were facing...

I had only gone as high as 5.2.32, because that was the highest version in the Linux Mint repos

Careful there... The Mint repos contain the Mint forked version of VirtualBox. Always go for the official one from the Linux Downloads section of VirtualBox. You can even add VirtualBox as a repository, so you could use your traditional install/upgrade/uninstall tools.

I am THRILLED to report that the problem is resolved!

Glad you got it going. And thank you for marking the topic as [Solved]...

[dentonesque]

Unfortunately, I spoke too soon

Because I wasn't getting the error I was before, and I could see the files in the LVM container, I assumed everything was back to normal. But it's not. Now I can barely do anything within the LVM container before it completely freezes my guest machine. It's highly unstable. Very disappointing.

Ah, the "loop device" bug! Didn't/couldn't make the connection with what you were facing...

You seem to be aware of a related problem. Can you point me to any specific resources?

Thanks!

[fth0]

Depending on what you want to achieve, there may be other alternatives besides using a shared folder:

1. You could use VBoxManage convertfromraw to convert a LUKS/LVM container file to a VDI file and attach the latter as an additional disk drive to your VM, if you only want to access the contents from the guest (and not also from the host).

[Speculation on]
2. There is a VBoxManage internalcommands createrawvmdk command, which is usually used to create a link to a raw hard disk. Maybe it can also be used to create a link to a mapped container device on the host (I don't know and haven't tried it). Details about this (potentially dangerous) command can be found in the VirtualBox User Manual.
[Speculation off]

[dentonesque]

Depending on what you want to achieve, there may be other alternatives besides using a shared folder:

Thanks for the suggestions! I'll look into that.