search for: lvuuid

virt-sparsify shouldn't die if sparsifying a filesystem that contains read-only LVs. https://bugzilla.redhat.com/show_bug.cgi?id=1185561 I thought about trying to make the LV writable temporarily, but I suspect that if the sysadmin has made the LV read-only, then they probably did it for a reason, so we shouldn't touch it. Rich.

This patcheset fixes errors in virt-sysprep and virt-sparsify. Here we have a common functionality: is_btrfs_subvolume. Doesn't it make sense to turn it into guestfs API? Also I found an issue. In 'virt-sysprep fs-uuids', the uuids for ALL filesystems are regenerated as many times as many roots are in guest. Is it done intentionally? Maxim Perevedentsev (3): mllib: add checking

...4,8 @@ let is_read_only_lv (g : G.guestfs) = if lv_attr.[1] = 'r' then Some lv_uuid else None ) lvs in fun fs -> - if g#is_lv fs then ( + (* Btrfs subvolumes are NOT read-only LVs *) + if not (is_btrfs_subvolume g fs) && g#is_lv fs then ( let uuid = g#lvuuid fs in List.exists (fun u -> compare_lvm2_uuids uuid u = 0) ro_uuids ) -- 1.8.3.1

...Z#1185561). *) +let is_read_only_lv (g : G.guestfs) = + let lvs = Array.to_list (g#lvs_full ()) in + let romap = List.map ( + fun { G.lv_uuid = lv_uuid; lv_attr = lv_attr } -> + lv_uuid, lv_attr.[1] = 'r' + ) lvs in + fun fs -> + if g#is_lv fs then ( + let uuid = g#lvuuid fs in + assoc ~cmp:compare_lvm2_uuids ~default:false uuid romap + ) + else false -- 2.1.0

...G.guestfs) = > + let lvs = Array.to_list (g#lvs_full ()) in > + let romap = List.map ( > + fun { G.lv_uuid = lv_uuid; lv_attr = lv_attr } -> > + lv_uuid, lv_attr.[1] = 'r' > + ) lvs in > + fun fs -> > + if g#is_lv fs then ( > + let uuid = g#lvuuid fs in > + assoc ~cmp:compare_lvm2_uuids ~default:false uuid romap > + ) > + else false This looks to me that it would go through all the LVs, even RW ones, when is_read_only_lv is invoked, right? Considering that we get a list of all the LVs anyway when doing: > + let is_...

I'm currently working on gobject bindings for libguestfs. I haven't got as far as compiling anything yet, but I've attached the C header for initial review. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -------------- next part -------------- An embedded and

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

If we want to permit more than 255 drives to be added, then we will have to add the disks to the same virtio-scsi target using different unit (LUN) numbers. Unfortunately SCSI LUN enumeration in the Linux is not deterministic (eg. two disks with target=0, lun=[0,1] can be enumerated as /dev/sda or /dev/sdb randomly). Dealing with that will require some very complex device name translation on the

...quot;], []; + style = RString "uuid", [String (PlainString, "vgname")], []; shortdesc = "get the UUID of a volume group"; longdesc = "\ This command returns the UUID of the LVM VG named C<vgname>." }; { defaults with name = "lvuuid"; added = (1, 0, 87); - style = RString "uuid", [Device "device"], []; + style = RString "uuid", [String (Device, "device")], []; shortdesc = "get the UUID of a logical volume"; longdesc = "\ This command returns the UUID...

Very large but mechanical change to the generator. Rich.

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.