Bug 2299474 - virt-v2v-in-place permission denied creating passt1.pid
Summary: virt-v2v-in-place permission denied creating passt1.pid
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-07-23 14:42 UTC by David Vitek
Modified: 2024-08-01 11:09 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-08-01 10:48:20 UTC
Embargoed:


Attachments (Terms of Use)

Description David Vitek 2024-07-23 14:42:10 UTC
Description of problem:

I was hoping to use virt-v2v-in-place to get virtio drivers installed into a windows VM, rather than doing it manually.  I semi-manually imported it from vmware into libvirt using qemu-img and virt-install, because virt-v2v couldn't identify the OS on the disk.  I've done this on about 65 VMs.  Something like 20% had this issue (inspection could not detect the source guest).  I don't know what made that 20% different.

In any case, because I didn't use virt-v2v to do the conversion from vmware, the virtio drivers did not get installed, which is why I'm running virt-v2v-in-place.

The VM is registered with libvirt with a qcow2 image for the disk.  It boots, so things aren't totally screwed up.

If I run virt-v2v-in-place as myself, I get this error:

virt-v2v-in-place vmname
...
mnbdkit: file[1]: error: open: /dev/dm-1: Permission denied

I assume this is expected behavior and I have to run as root.  So I try:

sudo virt-v2v-in-place vmname
...
virt-v2v-in-place: error: libguestfs error: passt exited with status 1

Digging deeper into this using strace, I think this problem is stemming from:

[pid 309845] geteuid()                  = 0
[pid 309845] mkdir("/tmp/libguestfsyIUHch", 0700) = 0
[pid 309845] chmod("/tmp/libguestfsyIUHch", 0755) = 0
[pid 309845] bind(3, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/guestfsd.sock"}, 110) = 0
[pid 309871] execve("/usr/bin/passt.avx2", ["passt", "--one-off", "--socket", "/tmp/libguestfsyIUHch/passt.sock", "--pid", "/tmp/libguestfsyIUHch/passt1.pid", "--address", "redacted", "--netmask", "16", "--mac-addr", "redacted", "--gateway", "redacted"], 0x7ffcb400e7b0 /* 19 vars */) = 0
[pid 309871] geteuid()                  = 0
[pid 309871] openat(AT_FDCWD, "/proc/self/uid_map", O_RDONLY|O_CLOEXEC) = 5
[pid 309871] setuid(65534)              = 0
[pid 309871] connect(7, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/passt.sock"}, 110) = -1 ENOENT (No such file or directory)
[pid 309871] unlink("/tmp/libguestfsyIUHch/passt.sock") = -1 ENOENT (No such file or directory)
[pid 309871] bind(6, {sa_family=AF_UNIX, sun_path="/tmp/libguestfsyIUHch/passt.sock"}, 110) = -1 EACCES (Permission denied)
UNIX domain socket bound at /tmp/libguestfsyIUHch/passt.sock
    kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/tmp/libguestfsyIUHch/passt.
[pid 309871] write(2, "\n", 1 <unfinished ...>
[pid 309871] openat(AT_FDCWD, "/tmp/libguestfsyIUHch/passt1.pid", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0600) = -1 EACCES (Permission denied)

Note the setuid call that switches away from root... after creating the temp dir as root.

passt is switching users to someone who does not have permission to write to the temp directory created by the parent process.  My machine does not have a user 65534.

Version-Release number of selected component (if applicable):

$ virt-v2v-in-place --version
virt-v2v-in-place 2.4.0

$ passt --version
passt unknown version

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04 LTS
Release:        24.04
Codename:       noble

Installed using apt-get on ubuntu24.04.  This is pretty much a fresh install.

How reproducible:

100%

I am suspicious this would happen for any libvirt VM on this host based on how early it happens.  Also happens using -i libvirtxml.

Steps to Reproduce:
1. sudo virt-v2v-in-place vmname

Actual results:
virt-v2v-in-place: error: libguestfs error: passt exited with status 1

Expected results:
exit code 0

Additional info:

Using -i disk seems to avoid using passt and triggering the problem.  However, after getting past this passt problem, I hit the same problem virt-v2v originally did:

inspection could not detect the source guest

so looks like I'll be installing the virtio drivers from inside the guest.

Comment 1 Richard W.M. Jones 2024-07-23 15:26:19 UTC
I suspect this could be the same issue as:

https://issues.redhat.com/browse/RHEL-36045

Comment 3 Stefano Brivio 2024-07-23 15:48:52 UTC
(In reply to David Vitek from comment #0)
> $ passt --version
> passt unknown version

Weird, I'll need to look into this. I maintain the Debian package, which is automatically synchronised and built for Ubuntu, but I don't know why this happens (on Ubuntu).

Meanwhile, could you please share the output of 'apt-cache policy passt', so that we know what the actual version is?

The problem you described should be fixed by https://passt.top/passt/commit/?id=c9b24134656925e53fea3cde0b33ab143dcd84af, so I suspect that the version you have installed at the moment doesn't contain the fix.

Comment 6 Stefano Brivio 2024-07-23 16:12:51 UTC
(In reply to Stefano Brivio from comment #3)
> (In reply to David Vitek from comment #0)
> > $ passt --version
> > passt unknown version
> 
> Weird, I'll need to look into this. I maintain the Debian package, which is
> automatically synchronised and built for Ubuntu, but I don't know why this
> happens (on Ubuntu).

This was fixed by https://salsa.debian.org/sbrivio/passt/-/commit/e2a0b460ac19345b622f0b6263473be8b8775907, but Ubuntu 24.04 doesn't have the fix yet (24.10 does).

> Meanwhile, could you please share the output of 'apt-cache policy passt', so
> that we know what the actual version is?
> 
> The problem you described should be fixed by
> https://passt.top/passt/commit/?id=c9b24134656925e53fea3cde0b33ab143dcd84af,
> so I suspect that the version you have installed at the moment doesn't
> contain the fix.

Same here: Ubuntu 24.04 has passt-0.0~git20240220.1e6f92b, which doesn't include the fix, while Ubuntu 24.10 ships passt-0.0~git20240624.1ee2eca, which is fixed.

It's not at all clear to me how updates are picked for Ubuntu 24.04 (you should probably report this issue on Launchpad). Meanwhile, would it be an option for you to install passt-0.0~git20240624.1ee2eca (https://packages.ubuntu.com/oracular/passt)?

Comment 7 David Vitek 2024-08-01 04:07:02 UTC
Yeah I have the same version you suspect:

$ apt-cache policy passt
passt:
  Installed: 0.0~git20240220.1e6f92b-1
  Candidate: 0.0~git20240220.1e6f92b-1
  Version table:
 *** 0.0~git20240220.1e6f92b-1 500
        500 http://us.archive.ubuntu.com/ubuntu noble/universe amd64 Packages
        100 /var/lib/dpkg/status

Given that I was already able to work around the issue, I don't particularly need the update right now.  However, I can try it if you are particularly interested in confirming it works.  Feel free to close the ticket.

Comment 8 Stefano Brivio 2024-08-01 10:41:19 UTC
(In reply to David Vitek from comment #7)
> Yeah I have the same version you suspect:
> 
> $ apt-cache policy passt
> passt:
>   Installed: 0.0~git20240220.1e6f92b-1
>   Candidate: 0.0~git20240220.1e6f92b-1
>   Version table:
>  *** 0.0~git20240220.1e6f92b-1 500
>         500 http://us.archive.ubuntu.com/ubuntu noble/universe amd64 Packages
>         100 /var/lib/dpkg/status

Thanks for checking.

> Given that I was already able to work around the issue, I don't particularly
> need the update right now.  However, I can try it if you are particularly
> interested in confirming it works.

Not so much, the issue is very well defined. And anyway it can only be fixed with a newer version of passt (or a backport) on Ubuntu 24.04, so the issue should be filed against Ubuntu, in case.

> Feel free to close the ticket.

Rich, I would close this if you agree.

Comment 9 Richard W.M. Jones 2024-08-01 10:48:20 UTC
I have closed -> currentrelease as it seems this should be fixed in Ubuntu 24.04 per
comment 6.  If the reporter has time it would be good to verify this is really the case.

Comment 10 Stefano Brivio 2024-08-01 11:09:02 UTC
(In reply to Richard W.M. Jones from comment #9)
> I have closed -> currentrelease as it seems this should be fixed in Ubuntu 24.04

24.10 (CURRENTRELEASE applies as well).


Note You need to log in before you can comment on or make changes to this bug.