date:20181002

Thanks for looking into this.

> it's 1) difficult to explain in
> the UI, 2)
+
> 2) has tricky operational caveats (see
> https://libvirt.org/formatdomain.html#elementsMemoryBacking),

Ok, I wasn't aware one needs to use hard_limit to make this safe for the host 
and that guests' memory usage on the host can grow arbitrarily. However, there 
should be values h0 and h1 such that hard_limit = h0 + h1 * maxMemory only 
waste a small amount of memory acceptable to normal users, maybe h0=256 MB and 
h1=1.05, and results in a low probability of hitting the limit. This extra 
memory usage could then be mentioned in the "locked" check box.

For myself, I think I will simply remove "locked" again as I also moved to 
using huge pages and I understand the SUSE documentation that huge pages are 
never swapped out.

> 3) has a
> limited audience who are already power users.

Given the simple, reproducible, non-power user situations in which my VMs have 
been swapped out so much that they became unusable (unresponsive to mouse 
clicks) over the last years, I'd expect that the majority of users would need 
this "locked" option. I only need to do something mundane as copying a large 
file from disk/SSD to a low-speed memory stick and from one minute to the next 
99% of my VM is no longer in RAM (without "locked"). With swap on spinning 
disks, swap out is fast because it's sequential but swap in is super slow 
because it's mostly random access. Before I learned about "locked", my best 
course of action was to "force off" the VM and start it again. (In some cases, 
swap usage went back to exactly 0, indicating that only the VM was swapped 
out. I guess that the kernel picks the largest idle process when it wants to 
make available some extra RAM for I/O.) 

What puzzles me is that experts and power users do not seem to have ever 
encountered such problems. On serverfault, the experts say it is perfectly 
fine that the VM is swapped out, arguing that the kernel's swap heuristics are 
carefully tuned and if the kernel decides to do so there must be a good reason 
and it must be for the better of overall performance. 

> virt-xml $VMNAME --edit --memorybacking locked=on
Thanks. I tested this and updated my serverfault answer accordingly.

> I'm thinking virt-manager really needs a raw XML editing
> mode.
If my own learning experience is representative, I'd say a tab "Advanced 
Settings" does not need an editor but just pointers to virt-xml (+ virsh edit 
if virt-xml cannot do all) and online resources / step-by-step examples / 
community wiki.

Joachim


___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [libvirt] question about syntax of storage volume element


On 10/02/2018 10:53 AM, Jim Fehlig wrote:

On 10/2/18 5:13 AM, Pavel Hrdina wrote:

On Mon, Oct 01, 2018 at 02:28:09PM -0400, Cole Robinson wrote:

On 09/28/2018 12:54 AM, Jim Fehlig wrote:
I've attempted to use virt-manager to create a new VM that uses a 
volume

from an rbd-based network pool, but have not been able to progress past
step 4/5 where VM storage is selected. It appears virt-manager has
problems properly detecting the volume as network-based storage, but
before investigating those further I have a question about the 
syntax of

the  element of a storage volume.


Yeah virt-manager is known to be lacking WRT rbd. I did some work a few
years back but didn't finish it. At least it doesn't know how to 
correctly
use a volume with any auth data in the XML. I need to get another rbd 
setup

to test with and fix it all


I was investigating the RBD support as well and in order to add proper
support for it into virt-manager we need to add support for secrets.


Right. But I was starting with the assumption that a "storage admin" 
setup an rbd-based pool, necessary secrets, etc. Then user creating a 
new VM could select existing volumes in the pool or create new ones at 
step 4/5 of the VM creation wizard. Currently a user can select an 
existing volume or create a new one, but can't progress beyond that 
point. I have a hack (attached, based against 1.5.1) to workaround the 
problem in virt-manager. Commit 582c1d3d fixed virt-install to copy auth 
data from the pool to the device config in domXML and as a first step 
I'm trying to do the same with virt-manager.




dropping libvir-list and adding virt-tools-list

Cool, thanks for working on this. Can you provide:

- pool XML you are using
- vol XML
- the backtrace you are hitting

Maybe I can distill that stuff into something that's easy to reproduce 
with the testdriver


- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager PATCH] osinfo: warn when using deprecated osinfo IDs


On 10/02/2018 07:53 AM, Pino Toscano wrote:

At some point in the future it could be a good idea to drop the _aliases
mapping altogether; it will be hard to do so, in case the users are not
informed that they are using a deprecated ID.



I had a similar thought just a few days ago!


Signed-off-by: Pino Toscano 
---
  virtinst/osdict.py | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/virtinst/osdict.py b/virtinst/osdict.py
index 39422233..b78bcedd 100644
--- a/virtinst/osdict.py
+++ b/virtinst/osdict.py
@@ -192,7 +192,14 @@ class _OSDB(object):
  return osobj
  
  def lookup_os(self, key):

-key = self._aliases.get(key) or key
+try:
+mapped_key = self._aliases[key]
+logging.warning(_("Using a deprecated Guest osinfo %s, "
+  "%s will be used instead"),
+key, mapped_key)
+key = mapped_key
+except KeyError:
+pass


I kinda hate the EAFP pattern for this type of stuff so I tweaked it. I 
also tweaked the message to indicate the alias will be removed some day. 
Pushed now


Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [PATCH] cli: add memory backing access_mode & source_type


On 10/01/2018 02:53 PM, Marc-André Lureau wrote:

Hi

On Mon, Oct 1, 2018 at 9:20 PM Cole Robinson  wrote:


On 09/17/2018 06:59 AM, marcandre.lur...@redhat.com wrote:

From: Marc-André Lureau 

Allow to set some memory backing options, ex:
--memorybacking access_mode=shared,source_type=anonymous

Signed-off-by: Marc-André Lureau 
---
   .../cli-test-xml/compare/virt-install-singleton-config-2.xml  | 4 
   tests/clitest.py  | 2 +-
   virtinst/cli.py   | 2 ++
   virtinst/domain/memorybacking.py  | 2 ++
   4 files changed, 9 insertions(+), 1 deletion(-)


Patch looks good, thanks. I'll push after libvirt patches land


The attributes/properties set here are long supported by libvirt.

Only the value "memfd" for source_type I use in the test isn't yet supported.

thanks



Oh I must have screwed up grepping, I thought source type= was new. I'll 
push it but with memfd switched to anonymous... doesn't seem to cause an 
issue that 'memfd' is passed but libvirt doesn't support it yet, which 
is a bit strange, usually it chokes on unknown enum values


- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [ [PATCH 0/3] Add SCSI persistent reservation support for LUN Passthrough


On 09/26/2018 08:36 AM, Michal Privoznik wrote:

On 09/25/2018 11:12 AM, Lin Ma wrote:

Lin Ma (3):
   cli: disk: add pr.managed=, pr.type=, pr.path= and pr.mode= support
   details: Add disk pr.managed and pr.path options to support SCSI PR
   addhardware: Add disk pr.managed and pr.path options to support SCSI
 PR

  man/virt-install.pod  | 13 +
  .../compare/virt-install-many-devices.xml |  9 +++
  tests/clitest.py  |  1 +
  ui/addhardware.ui | 56 ++
  ui/details.ui | 57 +++
  virtManager/addhardware.py| 42 ++
  virtManager/details.py| 47 ++-
  virtManager/domain.py | 15 -
  virtinst/cli.py   |  5 ++
  virtinst/devices/disk.py  |  9 +++
  10 files changed, 252 insertions(+), 2 deletions(-)



Not a virt-manager developer, but since I wrote libvirt part of the
feature here are my thoughts. Do whatever you want with it O:-)

I think virt-manager should support only managed mode, if anything. The
unmanaged mode is mostly for testing and requires some setting up on
administrator side. It is not secure either - domain running under any
seclabel must be able to connect to pr-helper socket.

Managed mode spawns one pr-helper per domain, kills it automatically on
domain shutdown and labels the socket correctly.



Yes I agree. This should be just a checkbox for 'Peristent Reservations' 
and hidden for non-scsi.


That said see the other mail I sent:
https://www.redhat.com/archives/virt-tools-list/2018-October/msg00021.html

If a raw XML editing mode works out, this is likely one of the UI 
options I would drop, it's a power user option only applicable to a 
particular advanced usecase. That said in the meantime I will accept a patch


Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [ [PATCH 1/3] cli: disk: add pr.managed=, pr.type=, pr.path= and pr.mode= support


On 09/25/2018 05:12 AM, Lin Ma wrote:

Enable the managed or unmanaged PR configuration to enable SCSI persistent
reservation for LUN Passthrough.

Signed-off-by: Lin Ma 
---
  man/virt-install.pod| 13 +
  .../compare/virt-install-many-devices.xml   |  9 +
  tests/clitest.py|  1 +
  virtinst/cli.py |  5 +
  virtinst/devices/disk.py|  5 +
  5 files changed, 33 insertions(+)

diff --git a/man/virt-install.pod b/man/virt-install.pod
index 657ef8cb..abb9d40d 100644
--- a/man/virt-install.pod
+++ b/man/virt-install.pod
@@ -739,6 +739,19 @@ Defines default behavior of the disk during disk 
snapshots.  See possible
  values in L,
  "snapshot" attribute of the  element.
  
+=item B

+
+It enables SCSI persistent reservations for LUN passthrough disks.
+For possible values, Please refer toPlease refer
+L,
+"reservations" attribute of the  element.
+
+e.g.
+
+--disk /dev/sdb,device=lun,bus=scsi,pr.managed=yes
+
+--disk 
/dev/sdc,device=lun,bus=scsi,pr.managed=no,pr.type=unix,pr.path=/tmp/pr-helper0.sock,pr.mode=client
+
  =back



I don't think this needs to be documented in the manpage. It's poweruser 
enough that users can figure it out on the command line via --disk help 
output. So please drop this bit


For new options I'm trying to get closer to the libvirt XML naming, so 
it's more discoverable and predictable. So I'd like the command line ot be


--disk 
reservations.managed=no,reservations.source.type=unix,reservations.source.path=/tmp/pr-helper0.sock,reservations.source.mode=client



  See the examples section for some uses. This option deprecates -f/--file,
diff --git a/tests/cli-test-xml/compare/virt-install-many-devices.xml 
b/tests/cli-test-xml/compare/virt-install-many-devices.xml
index 25070b1b..20071439 100644
--- a/tests/cli-test-xml/compare/virt-install-many-devices.xml
+++ b/tests/cli-test-xml/compare/virt-install-many-devices.xml
@@ -160,6 +160,15 @@


  
+
+  
+  
+
+  
+
+  
+  
+
  

  
diff --git a/tests/clitest.py b/tests/clitest.py
index 04795e05..47e2b6dc 100644
--- a/tests/clitest.py
+++ b/tests/clitest.py
@@ -438,6 +438,7 @@ c.add_compare(""" \
  --disk 
/var,device=floppy,address.type=ccw,address.cssid=0xfe,address.ssid=0,address.devno=01
 \
  --disk %(NEWIMG2)s,size=1,backing_store=/tmp/foo.img,backing_format=vmdk \
  --disk /tmp/brand-new.img,size=1,backing_store=/dev/default-pool/iso-vol \
+--disk 
path=/dev/sda,device=lun,bus=scsi,pr.managed=no,pr.type=unix,pr.path=/var/run/test/pr-helper0.sock,pr.mode=client
 \
  \
  --network 
user,mac=12:34:56:78:11:22,portgroup=foo,link_state=down,rom_bar=on,rom_file=/tmp/foo
 \
  --network bridge=foobar,model=virtio,driver_name=qemu,driver_queues=3 \
diff --git a/virtinst/cli.py b/virtinst/cli.py
index d7cb3ac3..b2adbcd2 100644
--- a/virtinst/cli.py
+++ b/virtinst/cli.py
@@ -2130,6 +2130,11 @@ ParserDisk.add_arg("geometry_heads", "geometry.heads")
  ParserDisk.add_arg("geometry_secs", "geometry.secs")
  ParserDisk.add_arg("geometry_trans", "geometry.trans")
  
+ParserDisk.add_arg("pr_managed", "pr.managed")

+ParserDisk.add_arg("pr_type", "pr.type")
+ParserDisk.add_arg("pr_path", "pr.path")
+ParserDisk.add_arg("pr_mode", "pr.mode")
+



  #
  # --network parsing #
diff --git a/virtinst/devices/disk.py b/virtinst/devices/disk.py
index d3ec27f9..8b125e16 100644
--- a/virtinst/devices/disk.py
+++ b/virtinst/devices/disk.py
@@ -836,6 +836,11 @@ class DeviceDisk(Device):
  geometry_secs = XMLProperty("./geometry/@secs", is_int=True)
  geometry_trans = XMLProperty("./geometry/@trans")
  
+pr_managed = XMLProperty("./source/reservations/@managed")

+pr_type = XMLProperty("./source/reservations/source/@type")
+pr_path = XMLProperty("./source/reservations/source/@path")
+pr_mode = XMLProperty("./source/reservations/source/@mode")
+


Similarly rename these properties reservation_X and reservation_source_X

Patch looks good otherwise.

Thanks,
Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [virt-manager gui feature request] check box for "locked" memory backing

On 09/19/2018 05:57 AM, Joachim Wagner wrote:

While various cli options for memory backing have been introduced in 2014, the
virt-manager GUI doesn't offer any memory options other than current and
maximum allocation under open -> view -> details -> memory. The "locked"
memory backing option is probably the most easy to to understand and can have
huge impact when the host also acts as a file server or runs write-intense
applications. It would be useful to many users to have a check box for it in
the GUI.

Indications for a need for this check box:
*
https://serverfault.com/questions/561446/how-can-i-keep-important-vms-in-memory-without-disabling-swap/
*
https://serverfault.com/questions/477886/why-does-host-swap-out-vms-when-there-are-16gb-of-buffer-cache-and-swappiness

The other options may also be useful but typical users will require much more
guidance than offered in the libvirt documentation. I only start understanding
them reading .

This is one of those XML bits that's questionable to expose in the UI.
It's very important for some users, but it's 1) difficult to explain in
the UI, 2) has tricky operational caveats (see
https://libvirt.org/formatdomain.html#elementsMemoryBacking), 3) has a
limited audience who are already power users.

There's already a fairly easy command line way to enable this option,
once you know what it is:

virt-xml $VMNAME --edit --memorybacking locked=on

As the years go on and these types of requests seem to increase in
frequency, I'm thinking virt-manager really needs a raw XML editing
mode. Power users can make tweaks to the XML without leaving the UI, and
it will take a lot of pressure off us to implement/maintain/test power
user type options. That way the UI can refocus on the 90% case.
Hopefully I can get time to experiment with it by the end of the year

- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] [libvirt-users] Virt-manager: Restricted networks

2018-10-02 Thread Laine Stump

On 10/02/2018 09:53 AM, Cole Robinson wrote:
> On 10/02/2018 08:50 AM, Olivier Léobal wrote:
>> Hello,
>>
>> 'Isolated' networks created in VMM (I’m running 1.4.3) still connect
>> to the host (as gateway). Is it possible to avoid this? It is my
>> understanding that QEMU provides a 'restrict' option for that, but I
>> don't understand it well, and can’t find it in VMM.
>>
> 
> ccing libvirt-users
> 
> That's expected of isolated mode, according to this:
> 
> https://wiki.libvirt.org/page/VirtualNetworking#Isolated_mode
> 
> I'm not sure if/how to go about creating a network that only VMs can
> communicate on

If you want a network that doesn't even allow connections between the
host and the guests, then you won't want DNS or DHCP running on the host
for that network either, and for that matter, you will want the host to
not have any IP address for that network. (Of course in this case the
guests on the network will need to have their IP addresses statically
configured, or you'll need to run your own dhcp server on one of the
guests).

If that is what you want, then you want a network declared like this:

  reallyisolated

This will setup a bridge that has no IP address on the host, no DHCP
server, and no DNS server, but the guests will still be able to
communicate among themselves.

If you want the host to handle dhcp requests from the guests, but not
allow any traffic, then you can add in an IP address with a 
section, but configure the firewall of the host to reject all traffic on
the bridge interface other than dhcp; guests will still be able to
communicate with each other.

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: Restricted networks


On 10/02/2018 08:50 AM, Olivier Léobal wrote:

Hello,

'Isolated' networks created in VMM (I’m running 1.4.3) still connect to 
the host (as gateway). Is it possible to avoid this? It is my 
understanding that QEMU provides a 'restrict' option for that, but I 
don't understand it well, and can’t find it in VMM.




ccing libvirt-users

That's expected of isolated mode, according to this:

https://wiki.libvirt.org/page/VirtualNetworking#Isolated_mode

I'm not sure if/how to go about creating a network that only VMs can 
communicate on


- Cole

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

> The "Force Off" is my current work around.

There is a risk though that you may not be able to trigger that action on 
time, e.g. due to a shaky network connection to the remote VM or a 
temperamental mouse.




___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

2018-10-02 Thread femi adegoke

>> If you need to create the VM but do not want it to start booting anything 
>> from
the VM's disks, consider temporarily ticking the box "Readonly" of each
virtual disk (+"Apply" button), start the VM, choose Virtual Machine -> Shut
Down -> Force Off <<

The "Force Off" is my current work around.
Ideally, there should be an option (like you've said) to Start (aka boot) vm or 
Finish (aka create) vm.

On Oct 2 2018, at 6:09 am, Joachim Wagner  wrote:
>
> > I just tried using the "import" function.
> > This does not work, it still wants to start the installation.
>
>
> I guess you checked the box "Customise configuration before install" in step 4
> of 4 and you see "Begin Installation" and "Cancel Installation" buttons in the
> window that allows you to configure the virtual hardware. These button labels
> are wrong in "import" mode. They should read "Start VM" and "Cancel VM
> creation" respectively.
>
> If you need to create the VM but do not want it to start booting anything from
> the VM's disks, consider temporarily ticking the box "Readonly" of each
> virtual disk (+"Apply" button), start the VM, choose Virtual Machine -> Shut
> Down -> Force Off and remove the tick(s) from "Readonly" again. Alternatively,
> or as an additional safety net, add a bootable CD/DVD to the VM and make it
> the first boot option.
>
> @virt-manager developers: As "import" mode does not involve installation,
> those button labels need to change depending on the mode. If this is difficult
> without duplicating the widget a simple workaround may be to use labels
> * "Begin Installation / Start VM" and
> * "Cancel Installation and/or VM Creation"
> in this window. If it is not difficult to modify the window depending on the
> creation mode, it would be nice to also get a button "Create VM without
> starting it" in "import" mode.
>
> Joachim
>
>
> ___
> virt-tools-list mailing list
> virt-tools-list@redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

On Tue, Oct 02, 2018 at 06:21:01AM -0700, femi adegoke wrote:
> Yes, Pavel that is correct, as in not wanting the guest to get started.
> 
> I was hoping I could use virt-manager to "create" templates by "creating" a 
> guest vm that is ready to be powered on whenever it's needed.
> I could do this in Hyper-V & was hoping for similar functionality.

As a workaround you can create and start the guest and shut it down
right after the creation is done.  But I guess that for the import
method it would make sense to add an option to just define the guest
without starting it.

Pavel

> 
> On Oct 2 2018, at 5:28 am, Pavel Hrdina  wrote:
> >
> > On Tue, Oct 02, 2018 at 04:34:22AM -0700, femi adegoke wrote:
> > > I just tried using the "import" function.
> > > This does not work, it still wants to start the installation.
> >
> >
> > So we need to agree on terminology:
> > If you are creating new guest using virt-manager GUI there are four
> > options: Local install media, Network install, Network Boot and Import.
> >
> > From virt-manager/virt-install point of view the first three options
> > has two phases, install phase and final phase. The install phase
> > usually uses a different domain definition that the final phase.
> > During the install phase user usually installs the OS inside the guest
> > and once the installation is completed the definition is changed and it
> > starts again to the final phase.
> >
> > In case of 'Import' installation there is no install phase, there is
> > only final phase.
> >
> > With virt-manager GUI the guest is always started no matter which
> > installation method is selected.
> >
> > From your description I'm guessing that you don't want the guest to be
> > started after it's created, that is not possible with virt-manager.
> >
> > Pavel


signature.asc
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] Virt-manager: Restricted networks

2018-10-02 Thread Olivier Léobal


Hello,

'Isolated' networks created in VMM (I’m running 1.4.3) still connect to 
the host (as gateway). Is it possible to avoid this? It is my 
understanding that QEMU provides a 'restrict' option for that, but I 
don't understand it well, and can’t find it in VMM.


Thanks very much for the help (and the software)

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

> If you need to create the VM but do not want it to start booting anything
> from the VM's disks, consider temporarily ticking the box "Readonly"

Actually this only protects the disk(s) from modification. If booting from the 
disk(s) would have other unwanted effects, e.g. network access or breaking out 
of the VM (malware), you need to configure the VM so that it won't boot from 
the disks such as

> [...] add a bootable CD/DVD to the VM and make it 
> the first boot option.




___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

> I just tried using the "import" function.
> This does not work, it still wants to start the installation.

I guess you checked the box "Customise configuration before install" in step 4 
of 4 and you see "Begin Installation" and "Cancel Installation" buttons in the 
window that allows you to configure the virtual hardware. These button labels 
are wrong in "import" mode. They should read "Start VM" and "Cancel VM 
creation" respectively.

If you need to create the VM but do not want it to start booting anything from 
the VM's disks, consider temporarily ticking the box "Readonly" of each 
virtual disk (+"Apply" button), start the VM, choose Virtual Machine -> Shut 
Down -> Force Off and remove the tick(s) from "Readonly" again. Alternatively, 
or as an additional safety net, add a bootable CD/DVD to the VM and make it 
the first boot option.

@virt-manager developers: As "import" mode does not involve installation, 
those button labels need to change depending on the mode. If this is difficult 
without duplicating the widget a simple workaround may be to use labels
 * "Begin Installation / Start VM" and
 * "Cancel Installation and/or VM Creation"
in this window. If it is not difficult to modify the window depending on the 
creation mode, it would be nice to also get a button "Create VM without 
starting it" in "import" mode.

Joachim



___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

2018-10-02 Thread femi adegoke

Yes, Pavel that is correct, as in not wanting the guest to get started.

I was hoping I could use virt-manager to "create" templates by "creating" a 
guest vm that is ready to be powered on whenever it's needed.
I could do this in Hyper-V & was hoping for similar functionality.

On Oct 2 2018, at 5:28 am, Pavel Hrdina  wrote:
>
> On Tue, Oct 02, 2018 at 04:34:22AM -0700, femi adegoke wrote:
> > I just tried using the "import" function.
> > This does not work, it still wants to start the installation.
>
>
> So we need to agree on terminology:
> If you are creating new guest using virt-manager GUI there are four
> options: Local install media, Network install, Network Boot and Import.
>
> From virt-manager/virt-install point of view the first three options
> has two phases, install phase and final phase. The install phase
> usually uses a different domain definition that the final phase.
> During the install phase user usually installs the OS inside the guest
> and once the installation is completed the definition is changed and it
> starts again to the final phase.
>
> In case of 'Import' installation there is no install phase, there is
> only final phase.
>
> With virt-manager GUI the guest is always started no matter which
> installation method is selected.
>
> From your description I'm guessing that you don't want the guest to be
> started after it's created, that is not possible with virt-manager.
>
> Pavel___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm

On Tue, Oct 02, 2018 at 04:34:22AM -0700, femi adegoke wrote:
> I just tried using the "import" function.
> This does not work, it still wants to start the installation.

So we need to agree on terminology:

If you are creating new guest using virt-manager GUI there are four
options: Local install media, Network install, Network Boot and Import.

From virt-manager/virt-install point of view the first three options
has two phases, install phase and final phase.  The install phase
usually uses a different domain definition that the final phase.
During the install phase user usually installs the OS inside the guest
and once the installation is completed the definition is changed and it
starts again to the final phase.

In case of 'Import' installation there is no install phase, there is
only final phase.

With virt-manager GUI the guest is always started no matter which
installation method is selected.

From your description I'm guessing that you don't want the guest to be
started after it's created, that is not possible with virt-manager.

Pavel

signature.asc
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Installing Ubuntu 18.04 as a guest from iso

On Thu, Jul 19, 2018 at 09:41:34AM -0700, Eric Fort wrote:
> I’m using Ubuntu 18.04 as a host os with kvm as a default hypervisor and 
> wanting to install an Ubuntu 18.04 guest from an iso. The most recent choice 
> shown for Ubuntu in virt-manager is  17.x. What options should I choose?  
> What exactly changes when one flavor of os is selected over another (say I 
> chose Windows, OS X, bsd, or some other linux flavor for this install) and 
> why does it matter?  Is there not simply a generic choice in the list?  How 
> could Ubuntu 18.04 be added to the list and maybe submitted as a patch?
> 

Hi, sorry for such late answer.  The selection of OS that would be
installed inside guest changes what type of devices are configured
for the guest and default amount of memory or number of vcpus and
default size of disk image.

If the newest version is missing you can use older version, it should
work but it might not have the best configuration, however, for linux
there is usually no difference between two latest versions.

The list of OSes is from osinfo-db project.  It is most likely already
fixed in upstream but not backported into fedora packages.

There is generic choice but it pick emulated devices instead of virtio
and that will have a huge performance effect.  Emulated devices are slow
because it has to emulate the same behavior as the real device.  Virtio
devices are written specifically for virtualization and they require
additional drivers inside the guest.  Most linux distribution have them
already in the kernel, for windows guests you need to install them
manually.

Pavel

signature.asc
Description: PGP signature
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

[virt-tools-list] [virt-manager PATCH] osinfo: warn when using deprecated osinfo IDs

2018-10-02 Thread Pino Toscano

At some point in the future it could be a good idea to drop the _aliases
mapping altogether; it will be hard to do so, in case the users are not
informed that they are using a deprecated ID.

Signed-off-by: Pino Toscano 
---
 virtinst/osdict.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/virtinst/osdict.py b/virtinst/osdict.py
index 39422233..b78bcedd 100644
--- a/virtinst/osdict.py
+++ b/virtinst/osdict.py
@@ -192,7 +192,14 @@ class _OSDB(object):
 return osobj
 
 def lookup_os(self, key):
-key = self._aliases.get(key) or key
+try:
+mapped_key = self._aliases[key]
+logging.warning(_("Using a deprecated Guest osinfo %s, "
+  "%s will be used instead"),
+key, mapped_key)
+key = mapped_key
+except KeyError:
+pass
 return self._all_variants.get(key)
 
 def lookup_os_by_media(self, location):
-- 
2.17.1

___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list

Re: [virt-tools-list] Virt-manager: create vm