Libguestfs - Jul 2020 - Re: virt-v2v - Window firstboot service questions

Hi,

It seems that on Windows we create the following dir:

/Program Files/Guestfs/Firstboot/

Where '/' is the os volume (where /Windows reside)

Is it possible that Program Files is not actually located on the os volume?
(i.e. C:\Windows, D:\Program Files on original vm)

Does virt-v2v or even libguestfs's inspect_os() even support that?
(Looking around in the code tells me that if the Windows vm has
multiple volumes, or even if the os drive letter is not 'C:', virt-v2v
will not work correctly)

Wouldn't it be safer to create the Guestfs dir directly on root, and
not use the Program Files if it might be on a different volume?

Sam

On Thu, Jul 23, 2020 at 12:28:17PM +0300, Sam Eiderman
wrote:
> Hi,
> 
> It seems that on Windows we create the following dir:
> 
> /Program Files/Guestfs/Firstboot/
> 
> Where '/' is the os volume (where /Windows reside)
> 
> Is it possible that Program Files is not actually located on the os volume?
> (i.e. C:\Windows, D:\Program Files on original vm)
I'm not sure - is this possible?
> Does virt-v2v or even libguestfs's inspect_os() even support that?
AFAIK we always put it on the "system" partition, which will be the
one where we found /Windows.  And that ought to work even if the
system isn't on C: although I suppose it's unlikely anyone has tested
that.
> (Looking around in the code tells me that if the Windows vm has
> multiple volumes, or even if the os drive letter is not 'C:',
virt-v2v
> will not work correctly)
>
> Wouldn't it be safer to create the Guestfs dir directly on root, and
> not use the Program Files if it might be on a different volume?
While putting it in "/Program Files" is probably wrong, there are a
couple of other considerations: We ought not to pollute C:\ with a new
directory and there are no obvious other places (C:\Temp maybe?).  But
more importantly there's a lot of downstream documentation covering
this log file, and so moving it is going to cause trouble collecting
logs from (Red Hat's) customers.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On Fri, Jul 24, 2020 at 12:49 AM Richard W.M. Jones <rjones@redhat.com>
wrote:
>
> On Thu, Jul 23, 2020 at 12:28:17PM +0300, Sam Eiderman wrote:
> > Hi,
> >
> > It seems that on Windows we create the following dir:
> >
> > /Program Files/Guestfs/Firstboot/
> >
> > Where '/' is the os volume (where /Windows reside)
> >
> > Is it possible that Program Files is not actually located on the os
volume?
> > (i.e. C:\Windows, D:\Program Files on original vm)
>
> I'm not sure - is this possible?
Yes, it's located in the registry:

Windows\CurrentVersion: ProgramFilesPath: "%ProgramFiles%"
(REG_EXPAND_SZ)
Windows\CurrentVersion: ProgramW6432Dir: "C:\Program Files" (REG_SZ)
>
> > Does virt-v2v or even libguestfs's inspect_os() even support that?
>
> AFAIK we always put it on the "system" partition, which will be
the
> one where we found /Windows.  And that ought to work even if the
> system isn't on C: although I suppose it's unlikely anyone has
tested
> that.
If E:\ is the system partition (and Program Files is located there),
notice that the following line:

loop "" "C:" ["Program Files";
"Guestfs"; "Firstboot"]

Will write "C:" explicitly in the registry, probably using
%SystemDrive% instead (and REG_EXPAND_SZ) would solve it.
>
> > (Looking around in the code tells me that if the Windows vm has
> > multiple volumes, or even if the os drive letter is not 'C:',
virt-v2v
> > will not work correctly)
> >
> > Wouldn't it be safer to create the Guestfs dir directly on root,
and
> > not use the Program Files if it might be on a different volume?
>
> While putting it in "/Program Files" is probably wrong, there are
a
> couple of other considerations: We ought not to pollute C:\ with a new
> directory and there are no obvious other places (C:\Temp maybe?).  But
> more importantly there's a lot of downstream documentation covering
> this log file, and so moving it is going to cause trouble collecting
> logs from (Red Hat's) customers.
I understand, as I'm creating a fork of this behavior and I don't need
to take existing customers into account, I think I'll go with
"C:\"
directly as I do not think we should consider not polluting the
customer's "C:\" drive.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org
>
Thanks!