I read the first email, you don't need to keep sending it.
If you upgrade RHEL from 8.2 to the latest (8.8 or 8.9) you
will get libguestfs 1.44.0.
If you upgrade to RHEL 9 you will get libguestfs 1.50.1.
Since you have (still) not described the exact environment you're
using, or even accuratel
Hi Richard,
Yes, you are correct my ask is without upgrading OS version(from 8.2 to 9.0) is
it possible to upgrade libguestfs alone to different versions.
Thanks
Teja
-Original Message-
From: Richard W.M. Jones
Sent: Monday, September 25, 2023 2:36 PM
To: Teja Konapalli
Cc: libguestfs
On Mon, Sep 25, 2023 at 09:09:32AM +, Teja Konapalli wrote:
> Hi Richard,
>
> Yes, you are correct my ask is without upgrading OS version(from 8.2
> to 9.0) is it possible to upgrade libguestfs alone to different
> versions.
No, that is not supported.
Rich.
> Teja
>
> -Original Message-
On 23.09.23 19:37, Laszlo Ersek wrote:
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
On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> On 23.09.23 19:37, Laszlo Ersek wrote:
> >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
On Mon, Sep 25, 2023 at 01:14:40PM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> > On 23.09.23 19:37, Laszlo Ersek wrote:
> > >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 1
On Mon, Sep 25, 2023 at 01:25:06PM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 25, 2023 at 01:14:40PM +0100, Richard W.M. Jones wrote:
> > On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> > > On 23.09.23 19:37, Laszlo Ersek wrote:
> > > >On 9/22/23 16:47, Lee Garrett wrote:
> > > >
On Mon, Sep 25, 2023 at 10:16:10AM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 25, 2023 at 09:09:32AM +, Teja Konapalli wrote:
> > Hi Richard,
> >
> > Yes, you are correct my ask is without upgrading OS version(from 8.2
> > to 9.0) is it possible to upgrade libguestfs alone to different
> >
This change simply adds the flag to guestcaps, and sets it to always
true, so there is no change to the output.
---
lib/types.mli | 5 +
convert/convert_linux.ml | 1 +
convert/convert_windows.ml | 1 +
lib/types.ml | 3 +++
4 files changed, 10 insertions(+)
diff
---
output/create_libvirt_xml.ml | 10 --
tests/test-v2v-i-ova.xml | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 964acd25fd..f97272ca31 100644
--- a/output/create_libvirt_xml.ml
+++ b/output/crea
I didn't set the -rtc flag in the normal (UTC) case as that is the
default.
---
output/output_qemu.ml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/output/output_qemu.ml b/output/output_qemu.ml
index 57b1e58da2..a9d7b37071 100644
--- a/output/output_qemu.ml
+++ b/output/output_qemu.ml
@@ -
---
output/create_kubevirt_yaml.ml | 5 +
1 file changed, 5 insertions(+)
diff --git a/output/create_kubevirt_yaml.ml b/output/create_kubevirt_yaml.ml
index 689555e4dc..b96c742832 100644
--- a/output/create_kubevirt_yaml.ml
+++ b/output/create_kubevirt_yaml.ml
@@ -54,6 +54,11 @@ let create_ku
[Alice: See patch 2]
[This patch is a bit rough, it could do with better commit messages
and some tests. Please test it to see if it solves the Windows
conversion issue described in the thread below.]
We currently do not set any field in guest output. Most
Windows guests expect the BIOS to be
Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
"RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
set to localtime (not present) or UTC (present and set to 1).
See: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
See:
https://listman.redh
On Mon, Sep 25, 2023 at 04:26:59PM +0200, Alice Frosi wrote:
> Hi Rich,
>
> On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones wrote:
>
> [Alice: See patch 2]
>
>
> I'm not 100% sure about the source of this work. However, we had in
> KubeVirt people interested in using localtime with Windo
Hi Rich,
On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones
wrote:
> [Alice: See patch 2]
>
I'm not 100% sure about the source of this work. However, we had in
KubeVirt people interested in using localtime with Windows [1]. Yes, I see
that you pointed to that PR in patch 2. The problem with tha
Hi Richard/Eric,
I wanted to take a moment to express my sincere gratitude for your invaluable
contributions to "libguestfs" project.
And assistance with current issue "mount_local: unknown option 684826080".
The issue has been successfully resolved and our project is back on track.
Just to g
On Mon, Sep 25, 2023 at 04:26:59PM +0200, Alice Frosi wrote:
> Hi Rich,
>
> On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones
> wrote:
>
> > [Alice: See patch 2]
> >
>
> I'm not 100% sure about the source of this work. However, we had in
> KubeVirt people interested in using localtime with Win
On 9/25/23 16:04, Richard W.M. Jones wrote:
> ---
> output/create_libvirt_xml.ml | 10 --
> tests/test-v2v-i-ova.xml | 1 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
> index 964acd25fd..f97272ca31 1
On 9/25/23 16:04, Richard W.M. Jones wrote:
> [Alice: See patch 2]
>
> [This patch is a bit rough, it could do with better commit messages
> and some tests. Please test it to see if it solves the Windows
> conversion issue described in the thread below.]
>
> We currently do not set any field in
On 9/25/23 17:48, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
>> [Alice: See patch 2]
>>
>> [This patch is a bit rough, it could do with better commit messages
>> and some tests. Please test it to see if it solves the Windows
>> conversion issue described in the thread below.
On Mon, Sep 25, 2023 at 05:47:26PM +0200, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
> > ---
> > output/create_libvirt_xml.ml | 10 --
> > tests/test-v2v-i-ova.xml | 1 +
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/output/create_li
On Mon, Sep 25, 2023 at 05:49:18PM +0200, Laszlo Ersek wrote:
> On 9/25/23 17:48, Laszlo Ersek wrote:
> > On 9/25/23 16:04, Richard W.M. Jones wrote:
> >> [Alice: See patch 2]
> >>
> >> [This patch is a bit rough, it could do with better commit messages
> >> and some tests. Please test it to see i
On 9/25/23 16:04, Richard W.M. Jones wrote:
> Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
> "RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
> set to localtime (not present) or UTC (present and set to 1).
>
> See: https://wiki.archlinux.org/title/System_ti
On Mon, Sep 25, 2023 at 05:58:00PM +0200, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
> > Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
> > "RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
> > set to localtime (not present) or UTC (prese
Reviewed-by: Laszlo Ersek
---
output/create_kubevirt_yaml.ml | 5 +
1 file changed, 5 insertions(+)
diff --git a/output/create_kubevirt_yaml.ml b/output/create_kubevirt_yaml.ml
index 689555e4dc..e3a3f422df 100644
--- a/output/create_kubevirt_yaml.ml
+++ b/output/create_kubevirt_yaml.ml
@@ -5
Almost every Linux guest expects the motherboard Real Time Clock (RTC)
to be set to UTC and they adjust the time displayed based on their
timezone (which may be different for each user).
Most Windows guests expect the RTC to be set to the local time.
Windows can be configured to use a UTC clock.
The main changes are:
- BIOS -> RTC passim
- Split out the minor refactoring patch
- Enhanced commit messages
- Add Laszlo's R-b tag
Rich.
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
I didn't set the -rtc flag in the normal (UTC) case as that is the
default.
Reviewed-by: Laszlo Ersek
---
output/output_qemu.ml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/output/output_qemu.ml b/output/output_qemu.ml
index 57b1e58da2..1a5f7f7147 100644
--- a/output/output_qemu.ml
+++
Reviewed-by: Laszlo Ersek
---
output/create_libvirt_xml.ml | 6 ++
tests/test-v2v-i-ova.xml | 1 +
2 files changed, 7 insertions(+)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 12586fde17..30119d1357 100644
--- a/output/create_libvirt_xml.ml
+++ b/output
Minor refactoring of how section is generated in XML output.
There is no change in the output.
Reviewed-by: Laszlo Ersek
---
output/create_libvirt_xml.ml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 964
Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
"RealTimeIsUniversal" to see if the Windows guest is expecting RTC
set to localtime (not present) or UTC (present and set to 1).
See: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
See:
https://listman.redha
v6 was here:
https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg05231.html
Since then:
- patches v6 1-5 included in pull request
- patch v6 6 logic improved, now v7 patch 1
- rebased to master
Still needing review:
- patch 1,6,7,11,12
Eric Blake (12):
nbd/server: Support a request pa
Upcoming additions to support NBD 64-bit effect lengths allow for the
possibility to distinguish between payload length (capped at 32M) and
effect length (64 bits, although we generally assume 63 bits because
of off_t limitations). Without that extension, only the NBD_CMD_WRITE
request has a paylo
Although extended mode is not yet enabled, once we do turn it on, we
need to accept extended requests for all messages. Previous patches
have already taken care of supporting 64-bit lengths, now we just need
to read it off the wire.
Note that this implementation will block indefinitely on a buggy
Although extended mode is not yet enabled, once we do turn it on, we
need to reply with extended headers to all messages. Update the low
level entry points necessary so that all other callers automatically
get the right header based on the current mode.
Signed-off-by: Eric Blake
Reviewed-by: Vla
Instead of ignoring the low-level error just to refabricate our own
message to pass to the caller, we can just plumb the caller's errp
down to the low level.
Signed-off-by: Eric Blake
---
v5: set errp on more failure cases [Vladimir], typo fix
v4: new patch [Vladimir]
---
block/nbd.c | 18
Time to start supporting clients that request extended headers. Now
we can finally reach the code added across several previous patches.
Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up over
The NBD spec states that if the client negotiates extended headers,
the server must avoid NBD_REPLY_TYPE_BLOCK_STATUS and instead use
NBD_REPLY_TYPE_BLOCK_STATUS_EXT which supports 64-bit lengths, even if
the reply does not need more than 32 bits. As of this patch,
client->mode is still never NBD_
Update the client code to be able to send an extended request, and
parse an extended header from the server. Note that since we reject
any structured reply with a too-large payload, we can always normalize
a valid header back into the compact form, so that the caller need not
deal with two branche
All the pieces are in place for a client to finally request extended
headers. Note that we must not request extended headers when qemu-nbd
is used to connect to the kernel module (as nbd.ko does not expect
them, but expects us to do the negotiation in userspace before handing
the socket over to th
Once extended mode is enabled, we need to accept 64-bit status replies
(even for replies that don't exceed a 32-bit length). It is easier to
normalize narrow replies into wide format so that the rest of our code
only has to handle one width. Although a server is non-compliant if
it sends a 64-bit
Peform several minor refactorings of how the list of negotiated meta
contexts is managed, to make upcoming patches easier: Promote the
internal type NBDExportMetaContexts to the public opaque type
NBDMetaContexts, and mark exp const. Use a shorter member name in
NBDClient. Hoist calls to nbd_chec
The next commit will add support for the optional extension
NBD_CMD_FLAG_PAYLOAD during NBD_CMD_BLOCK_STATUS, where the client can
request that the server only return a subset of negotiated contexts,
rather than all contexts. To make that task easier, this patch
populates the list of contexts to r
Allow a client to request a subset of negotiated meta contexts. For
example, a client may ask to use a single connection to learn about
both block status and dirty bitmaps, but where the dirty bitmap
queries only need to be performed on a subset of the disk; forcing the
server to compute that info
45 matches
Mail list logo
