4:28 a.m.
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
4:49 p.m.
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
1:02 a.m.
On Fri, Jul 24, 2020 at 12:49 AM Richard W.M. Jones <rjones(a)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!
1561
days inactive
1564
days old
2 comments
2 participants
participants (2)
-
Richard W.M. Jones -
Sam Eiderman