[Libguestfs] Libguestfs desired version installation
Hi Richard , Happy weekend. I had one question regarding desired version installation of libguestfs, suppose if had RHEL 8.0 default libguestfs is 1.38.0 and I want to install 1.50.0 in same machine is it possible to install? Thanks Teja K ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] nbdinfo default output [was: [libnbd PATCH v2 6/6] info: Tolerate missing size]
On 9/22/23 16:14, Eric Blake wrote: > On Fri, Sep 22, 2023 at 09:03:53AM -0500, Eric Blake wrote: $ ./run nbdinfo nbd://localhost protocol: newstyle-fixed without TLS, using extended packets ... block_size_maximum: 33554432 > > For the human-readable output, should we also be using human_size() on > the block_size_* values? I'd find: > > block_size_minimum: 1 > block_size_preferred: 4096 (4K) > block_size_maximum: 33554432 (32M) > > somewhat easier to read. Right, that looks very convenient! Thanks! Laszlo > I don't know if the JSON version would need > to output that extra information, though. But that's a question > independent of this patch series. > ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot
On 9/22/23 16:47, Lee Garrett wrote:
> On 22.09.23 14:54, Richard W.M. Jones wrote:
>> On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
>>> On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
On 21.09.23 19:43, Richard W.M. Jones wrote:
> So this is probably another instance or variation of the timezone
> formatting problem (of schtasks). Which version of virt-v2v is this?
> I want to check that you have a version with all the latest patches in
> this area.
It's 2.2.0-1 from Debian (12) bookworm. I've verified that it
doesn't have any distro-specific patches.
(https://salsa.debian.org/libvirt-team/virt-v2v/-/tree/debian/master/debian
would have a patches/series file in this case)
>>>
>>> The timezone fixes are:
>>>
>>> commit 597d177567234c3a539098c423649781424eeb6f
>>> Author: Laszlo Ersek
>>> Date: Tue Mar 8 15:30:51 2022 +0100
>>>
>>> convert_windows: rewrite "configure_qemu_ga" script purely in
>>> PowerShell
>>>
>>> commit d9dc6c42ae64ba92993dbd9477f003ba73fcfa2f
>>> Author: Richard W.M. Jones
>>> Date: Fri Nov 12 08:47:55 2021 +
>>>
>>> convert/convert_windows.ml: Handle date formats with dots
>>> instead of /
>>>
>>> They are all included in >= 2.0
>>>
>>> I wonder if 597d177567 has a subtle flaw, or if we introduced a bug
>>> somewhere when refactoring this code later.
>>>
>>> Lee: Do you have a theory about exactly what is wrong with the
>>> schtasks date? Like what was it supposed to be, assuming it was 120
>>> seconds in the future from boot time, versus what it was set to:
>>>
Firstboot-qemu-ga 9/21/2023 4:04:00 PM Ready
>>>
>>> Could a date or time field have not been swapped or been corrupted
>>> in some predictable way?
>>
>> Or in even simpler terms, what is the time (and timezone) that
>> this ^^^ machine was booted?
>
> I believe I have it figured out.
> The guest local time is currently 7:08 AM (a few minutes after
> firstboot/provisioning), pacific daylight time (UTC-7, though Windows
> displays it as "UTC-08:00"). This is the timezone that the guest comes
> configured with at first boot. The task is scheduled for 2:01 PM,
> meaning it's scheduled to run ~7 hours in the future.
>
> So it seems like the task was meant to be scheduled for 2:01 PM UTC (=
> 7:01 AM PDT), but for some reason was scheduled for 2:01 PM *local time*.
>
> From what I can see, the host machine time zone is irrelevant (UTC+2).
>
> I don't know where the timezone mixup comes from, though. Running
> `(get-date)` in the powershell at this point correctly returns the local
> time (7:08 AM). I guess during injection the time is in UTC, and
> schtasks.exe has no awareness of timezones?
Right, I think there is a timezone disagreement between how we format the
timestamp and how schtasks.exe takes it.
What matters here is the /ST (start time) flag.
Today we have (in the common submodule):
add "$d = (get-date).AddSeconds(120)";
add "$dtfinfo = [System.Globalization.DateTimeFormatInfo]::CurrentInfo";
add "$sdp = $dtfinfo.ShortDatePattern";
add "$sdp = $sdp -replace 'y+', ''";
add "$sdp = $sdp -replace 'M+', 'MM'";
add "$sdp = $sdp -replace 'd+', 'dd'";
add "schtasks.exe /Create /SC ONCE `";
add " /ST $d.ToString('HH:mm') /SD $d.ToString($sdp) `";
add " /RU SYSTEM /TN Firstboot-qemu-ga `";
add (sprintf " /TR \"C:\\%s /forcerestart /qn /l+*vx C:\\%s.log\""
msi_path msi_path);
Note that for the /ST option's argument, we only perform the following steps:
$d = (get-date).AddSeconds(120)
/ST $d.ToString('HH:mm')
This actually goes back to commit dc66e78fa37d ("windows: delay installation of
qemu-ga MSI", 2020-03-10). The timestamp massaging we've since done only
targeted the /SD (start date) option, not the start time (/ST) one!
So the problem may be that
(get-date).AddSeconds(120).ToString('HH:mm')
formats the hour:minute timestamp in UTC (why though?), but the /ST option
takes hour:minute in local time.
Interestingly, DateTime objects seem to have a "Kind" property, which may be
Utc, Local, or Unspec.
https://learn.microsoft.com/en-us/dotnet/api/system.datetime.kind
It seems to be used when converting from UTC to local or vice versa, and it
probably influences how ToString() behaves too. I thought "get-date" returned a
Local one, and /ST took a local one as well, but perhaps "get-date" returns a
UTC timestamp in this case (when run from the script)?
Laszlo
>
>>
>> Rich.
>>
>>> The code we run is here:
>>>
>>> https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L571
>>>
>>> Ming: this could be a bug affecting PST (UTC-8) guests, perhaps
>>> somehow related to having a single digit month field?
>>>
>>> Rich.
>>>
>>> --
>>> Richard Jones, Virtualization Group, Red Hat
>>> http://people.redhat.com/~rjones
>>> Read
Re: [Libguestfs] Some comments on the libnbd apk in Alpine
On Sat, Sep 23, 2023 at 11:39:12AM +0200, Sean McAvoy wrote: > Hello Richard, > I have updated the version to 1.16.0 and integrated your suggestions in Merge > Request [1]. > I have stared the project and will get updates when new releases are made and > will update the Alpine package soon after. Great thanks. Just a note that the stable branch (1.16.4) has a few fixes: https://download.libguestfs.org/libnbd/1.16-stable/ Rich. > Thanks for making great software. > > Sean > > > [1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/52132 > > On Thu, Sep 21, 2023 at 6:02 PM Richard W.M. Jones wrote: > > Hi Sean, the maintainers of libnbd here. Thanks for packaging libnbd > in Alpine: > > https://git.alpinelinux.org/aports/tree/testing/libnbd/APKBUILD > > I have a few comments: > > (1) The url field should be "https://gitlab.com/nbdkit/libnbd; > (The one you are using is an old, stale mirror) > > (2) libxml2-dev is not listed as a dependency. > > We had a request from an Alpine user to add this dependency because it > enables several important features in libnbd, namely NBD URI support > and some utilities which require URI support. > > It shouldn't be too much trouble to add since it appears that libxml2 > is already built in Alpine. > > (3) libnbd 1.18 (next stable) will be released in a week or two: > https://listman.redhat.com/archives/libguestfs/2023-September/032590.html > > If you have any questions or comments about the package you can send > them to me and/or the mailing list (without subscribing if you don't > want to). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/ > ~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > > -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Some comments on the libnbd apk in Alpine
Hello Richard, I have updated the version to 1.16.0 and integrated your suggestions in Merge Request [1]. I have stared the project and will get updates when new releases are made and will update the Alpine package soon after. Thanks for making great software. Sean [1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/52132 On Thu, Sep 21, 2023 at 6:02 PM Richard W.M. Jones wrote: > Hi Sean, the maintainers of libnbd here. Thanks for packaging libnbd > in Alpine: > > https://git.alpinelinux.org/aports/tree/testing/libnbd/APKBUILD > > I have a few comments: > > (1) The url field should be "https://gitlab.com/nbdkit/libnbd; > (The one you are using is an old, stale mirror) > > (2) libxml2-dev is not listed as a dependency. > > We had a request from an Alpine user to add this dependency because it > enables several important features in libnbd, namely NBD URI support > and some utilities which require URI support. > > It shouldn't be too much trouble to add since it appears that libxml2 > is already built in Alpine. > > (3) libnbd 1.18 (next stable) will be released in a week or two: > https://listman.redhat.com/archives/libguestfs/2023-September/032590.html > > If you have any questions or comments about the package you can send > them to me and/or the mailing list (without subscribing if you don't > want to). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > > ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
