search for: ubd

From: Pino Toscano <ptoscano@redhat.com> If the device name ends with a number, Linux uses partition names of the form <device>p<N>. Handle this case by knocking off the 'p' character. --- daemon/devsparts.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/daemon/devsparts.c b/daemon/devsparts.c index 5862ae2..b764f63 100644 --- a/daemon/devsparts.c +++

v1 was here: https://www.redhat.com/archives/libguestfs/2013-August/msg00005.html This now works, to some extent. The main problem now is that devices are named /dev/ubd[a-] which of course confuses everything. I'm thinking it may be easier to add a udev rule to rename them. Rich.

...ly_with_perror ("opendir: /sys/block"); - return NULL; - } - - for (;;) { - errno = 0; - d = readdir (dir); - if (!d) break; - - if (STREQLEN (d->d_name, "sd", 2) || - STREQLEN (d->d_name, "hd", 2) || - STREQLEN (d->d_name, "ubd", 3) || - STREQLEN (d->d_name, "vd", 2) || - STREQLEN (d->d_name, "sr", 2) || - (return_md && - STREQLEN (d->d_name, "md", 2) && c_isdigit (d->d_name[2]))) { - CLEANUP_FREE char *dev_path = NULL; -...

This is a User-Mode Linux backend for libguestfs. You can select it by doing: export LIBGUESTFS_BACKEND=uml export LIBGUESTFS_QEMU=/path/to/vmlinux Note we're reusing the 'qemu' variable in the handle for convenience. QEmu is not involved when using the UML backend. This almost works. UML itself crashes when the daemon tries to connect to the serial port. I suspect it's

..._func_t func) +foreach_block_device (block_dev_func_t func, bool return_md) { CLEANUP_FREE_STRINGSBUF DECLARE_STRINGSBUF (r); DIR *dir; @@ -60,7 +61,9 @@ foreach_block_device (block_dev_func_t func) STREQLEN (d->d_name, "hd", 2) || STREQLEN (d->d_name, "ubd", 3) || STREQLEN (d->d_name, "vd", 2) || - STREQLEN (d->d_name, "sr", 2)) { + STREQLEN (d->d_name, "sr", 2) || + (return_md && + STREQLEN (d->d_name, "md", 2) && c_isdigit (d->d_name[2]...

A couple of weeks ago I noted that shared segments weren't working. Alexandre said that he fixed it. I wasn't in the position to build a fresh wine at the time. I am now but it doesn't seem to work still. I replicated the problem with a test exe, the basic Hello, World generated by MS VC 6 for a Windows program, with a single variable in a shared segment that is statically

...on the guest side with devfs? How about udev? Does udev get boottime events to initialize the device nodes for the block devices? And what about sysfs? Is there a sysfs interface to see what has been mapped where and with what major and minor numbers? I''ve used to using UML, where devices ubd0 and onwards are UML block devices - they have their own major device number. They show up in devfs as /dev/ubd/disc0/disc, /dev/ubd/disc1/disc and so on. I think there was supposed to be a sysfs interface as well, but I''m not sure about that. So, how is this all handled in Xen? -- Naked...

...581fa0f..b64f6e3 100644 --- a/daemon/sync.c +++ b/daemon/sync.c @@ -86,7 +86,6 @@ fsync_devices (void) { DIR *dir; struct dirent *d; - char dev_path[256]; int fd; dir = opendir ("/sys/block"); @@ -105,7 +104,11 @@ fsync_devices (void) STREQLEN (d->d_name, "ubd", 3) || STREQLEN (d->d_name, "vd", 2) || STREQLEN (d->d_name, "sr", 2)) { - snprintf (dev_path, sizeof dev_path, "/dev/%s", d->d_name); + CLEANUP_FREE char *dev_path; + if (asprintf (&dev_path, "/dev/%s", d-&...

On 22/05/2019 14:02, Johannes Berg wrote: > Hi, > > While my main interest is mostly in UML right now [1] I've CC'ed the > qemu and virtualization lists because something similar might actually > apply to other types of virtualization. > > I'm thinking about adding virt-io support to UML, but the tricky part is > that while I want to use the virt-io basics

...581fa0f..b64f6e3 100644 --- a/daemon/sync.c +++ b/daemon/sync.c @@ -86,7 +86,6 @@ fsync_devices (void) { DIR *dir; struct dirent *d; - char dev_path[256]; int fd; dir = opendir ("/sys/block"); @@ -105,7 +104,11 @@ fsync_devices (void) STREQLEN (d->d_name, "ubd", 3) || STREQLEN (d->d_name, "vd", 2) || STREQLEN (d->d_name, "sr", 2)) { - snprintf (dev_path, sizeof dev_path, "/dev/%s", d->d_name); + CLEANUP_FREE char *dev_path; + if (asprintf (&dev_path, "/dev/%s", d-&...

v1 -> v2: - Use intprops macro suggested by danpb. Rich.

By passing root=UUID=... to supermin, we make the appliance boot process less sensitive to the non-deterministic process of scanning SCSI disks (of which much more to come). This patch should be tested alongside the supermin patch posted here: https://www.redhat.com/archives/libguestfs/2017-April/msg00174.html which in turn requires this supermin patch series:

This happens with GCC 7.0.1. The errors were all of the form: qemu-speed-test.c: In function 'main': qemu-speed-test.c:153:7: error: this statement may fall through [-Werror=implicit-fallthrough=] usage (EXIT_SUCCESS); ^~~~~~~~~~~~~~~~~~~~ qemu-speed-test.c:155:5: note: here default: ^~~~~~~ --- builder/index-validate.c | 2 +-

QEMU upstream has broken snapshot=on ... again. These two patches stop using it entirely. Instead we run 'qemu-img create' to create overlay disks as required. Note that the libvirt and UML backends were already doing this: The libvirt backend because <transient/> has never worked, and the UML backend was running uml_mkcow because the UML-equivalent syntax of snapshot=on was

...by setting the proc sysctl value to true: /proc/sys/kernel/firmware_config/force_sysfs_fallback diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 1bb8ec575352..fa0cd072f5a1 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -142,10 +142,10 @@ config BLK_DEV_UBD bool "Virtual block device" depends on UML ---help--- - The User-Mode Linux port includes a driver called UBD which will let - you access arbitrary files on the host computer as block devices. - Unless you know that you do not need such virtual block devic...

...by setting the proc sysctl value to true: /proc/sys/kernel/firmware_config/force_sysfs_fallback diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index 1bb8ec575352..fa0cd072f5a1 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -142,10 +142,10 @@ config BLK_DEV_UBD bool "Virtual block device" depends on UML ---help--- - The User-Mode Linux port includes a driver called UBD which will let - you access arbitrary files on the host computer as block devices. - Unless you know that you do not need such virtual block devic...

Version 1 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00003.html This patch series reimplements a few more APIs in OCaml, including some very important core APIs like ?list_filesystems? and ?mount?. All the tests pass after this. The selection of APIs that I have moved may look a little random, but in fact they are all APIs consumed by the inspection code (and some more

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

...t: scsi: sg: fix v3 compat read/write interface compat_ioctl: block: handle BLKREPORTZONE/BLKRESETZONE compat_ioctl: block: handle BLKGETZONESZ/BLKGETNRZONES compat_ioctl: block: handle add zone open, close and finish ioctl compat_ioctl: block: handle Persistent Reservations compaT_ioctl: ubd, aoe: use blkdev_compat_ptr_ioctl compat_ioctl: move CDROM_SEND_PACKET handling into scsi compat_ioctl: move CDROMREADADIO to cdrom.c compat_ioctl: cdrom: handle CDROM_LAST_WRITTEN compat_ioctl: block: handle cdrom compat ioctl in non-cdrom drivers compat_ioctl: add scsi_compat_ioctl co...

v2 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00008.html This series gets as far as a working (and faster) reimplementation of ‘guestfs_list_filesystems’. I also have another patch series on top of this one which reimplements the inspection APIs inside the daemon, but that needs a bit more work still, since inspection turns out to be a very large piece of code. Rich.